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1  Executive  Summary 

Three  topics  were  selected  as  targets  for  this  project,  program  correctness,  finite  state  devices,  and 
program  complexity  (timing).  A  variety  of  artifacts  were  developed  to  support  course  material, 
programming  assignments,  and  laboratory  assignments  in  the  mathematics  of  software  engineering.  Most 
of  these  artifacts  have  been  placed  in  the  PAL,  Public  Ada  Library.  A  few  more  artifacts  will  be  set  to 
the  PAL  after  they  have  been  classroom  tested. 

The  program  correctness  artifact  centers  on  an  artifact,  called  Assert.  Assert  is  an  Ada  package  that 
assists  users  in  testing  program  assertions.  The  finite  state  device  target  is  supported  by  several  artifacts. 
One  artifact  in  a  course  module,  with  laboratory  and  programming  assignments,  that  centers  on  the  use 
of  Hnite  state  device  concepts  in  programming  and  the  classical  representations  of  finite  state  devices  in 
Ada. 

The  second  finite  state  device  artifact  is  a  Turing  Madiine  simulator,  called  tm.  tm  simulates  a  taring 
machine  with  from  one  to  three  tapes  with  a  visual  representation  on  a  typical  text  screen.  The  simulator 
requires  a  VTIOO  compatible  terminal  (that  includes  any  PC  running  ANSI.SYS,  window  systems  using 
an  Xll  xterm  window),  tm  was  designed  using  an  object  oriented  approach,  hence  the  artifacts  support 
three  types  of  usage.  Besides  the  typical  taring  machine  building  assignments,  the  may  be  us^  to 
demonstrate  object  oriented  design  and  the  taring  simulator  may  be  as  a  programming  project,  by 
withholding  several  package  bodies  and  requiring  the  students  to  build  the  various  package  bodies. 

The  timing  target  centered  on  generalizations  of  the  classical  Towers  of  Hanoi  problem.  The 
traditional  Towers  of  Hanoi  problem  appears  in  many  computing  texts  as  a  recursion  example.  Our  study 
of  the  Towers  of  Hanoi  problem  led  to  several  surprises.  First,  the  "well  known”  timing  solution  for  the 
traditional  three  spindle  version  was  formally  proven  cmly  in  1981!  Also,  there  are  no  formal  proofs  for 
the  Towers  of  Hanoi  with  four  or  more  spindles.  There  do  exist  estimates  that  appeared  in  1941  as 
solutions  to  a  Problems  Section  entry  that  appeared  in  1939.  However,  none  of  the  solutions  contained 
formal  proofs.  This  problem  lends  itself  to  substantial  experimentation  among  the  students  as  they 
compete  to  develop  the  program  with  the  best  timing  results. 

All  software  developed  through  this  grant  has  been  forwarded  for  inclusion  in  the  Public  Ada  Library 
(PAL). 


2  Overview 

It  was  not  enough  to  simply  develop  course  materials  directed  at  the  mathematical  foundations  of 
software  engineering,  it  was  important  to  develr^  materials  that  could  be  integrated  into  existing  courses 
without  disrupting  or  displacing  existing  course  materials.  One  way  of  achieving  this  is  to  develop 
material  that  builds  upon  topics  that  are  already  in  the  curriculum.  Four  topics  that  are  frequently  found 
in  two  core  courses  were  select.  The  courses  were  the  second  course  in  computer  science  and  the  data 
structures  and  algorithm  course,  frequently  referred  to  as  the  ACM  Curriculum  courses,  CS  2  and  CS  7. 
These  courses  were  selected  because  all  computing  curriculum  either  contain  these  two  courses,  or  cover 
these  topics  in  other  core  courses. 
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Initially,  the  project  concentrated  on  three  topics,  program  correctness,  finite  state  devices,  and 
program  timing.  It  was  desirable  to  approach  each  topic  from  a  new  perspective  that  will  not  only  interest 
the  students,  but  interest  the  instructors  as  well.  For  example,  consider  ^e  topic  of  fuogram  correctness. 
This  is  usually  approached  from  a  theoretical  and  very  mathematical  point  of  view.  The  a[^>roach  take 
in  this  project  was  from  a  pragmatic  point  of  view,  using  assolions  to  locate  and  cturect  errcMs.  This 
point  of  view  demonstrates  that  program  cmrectness  can  play  an  important  role  throughout  the  entire 
software  life  cycle,  including  system  evaluation  and  maintenance. 

3  Assertions 

Proving  the  correctness  of  a  program  is  frequently  viewed  by  software  developers  as  an  esoteric 
academic  exercise.  This  point  of  view  can  be  readily  appreciated  when  one  reviews  the  various 
presentation  on  program  correctness  that  appears  in  current  text  books.  Frequently,  illustrations  of 
applications  of  program  conectness  concepts  are  after-the-fact  exercises  of  belaboring  the  obvious.  In 
some  cases  errors  exist  in  the  "proofs”.  Frequently  authors  avoid,  or  provide  a  poor  presentation,  on  cme 
of  the  major  tools  of  low  level  program  conectness  {U'oofs,  loop  invariants.  The  cunent  lack  of  utilization 
of  program  correctness  techniques  is  unfortunate  because  program  correctness  tedmiques  can  be  an 
invaluable  software  development  aids  that  may  be  employed  throughout  the  software  develq)ment  process, 
from  the  design  phase  through  software  maintenance  and  modificaticm. 

This  paper  describes  our  experience  designing  an  Ada  package  that  supports  practical  uses  of  program 
correctness  throughout  the  software  development  process.  The  package,  called  ASSERT,  was  originally 
designed  as  a  stand  alone  package  to  supports  the  pragmatic  use  of  program  correctness  with  its  major 
concentration  on  the  interface  between  the  design  and  implementation  phases  of  software  projects.  An 
early  version  of  the  Assert  package  was  designed  and  develq)ed  by  Jennifer  Pollack,  a  senior  Computer 
Science  major  at  the  University  of  Scranton. 

She  began  the  research  for  this  project  in  the  Spring  of  her  Junior  year  and  spent  the  summer 
reviewing  the  literature  on  program  correctness.  Because  of  her  preparation,  she  had  a  prototype 
completed  for  her  Senior  project  at  the  beginning  of  the  Fall  1991  semester.  This  allowed  us  to 
concentrate  on  the  issues  surrounding  methods  of  encouraging  potential  clients  to  use  the  ASSERT 
package.  Section  Two  describes  the  Assert  package  and  its  various  reporting  modes.  Section  Three 
illustrates  a  typical  use  of  the  Assert  package. 

Section  Four  presents  several  pragmatic  issues  surrounding  the  use  of  the  ASSERT  package.  The 
cunent  version  of  the  package  was  is  slightly  different  from  our  original  version  of  system.  Initially,  we 
found  attempts  to  use  the  Assert  package  to  be  inconvenient.  This  is  illustrated  in  this  paper  with  several 
examples  of  assertions  involving  classical  array  based  algorithms.  Initially,  the  problem  of  testing 
assertions  frequently  doubled  the  amount  of  code  that  was  written.  That  is,  the  code  to  perform  assertion 
testing  of  a  system  was  almost  equal  in  size  to  the  amount  of  code  in  the  original  system.  The  reason  for 
the  additional  code  was  that  we  wanted  assertion  testing  to  be  written  in  code  that  is  independent  from 
the  original  code  for  the  obvious  reason  (same  code  =  same  error). 

As  we  began  to  understand  how  to  design  good  iterators,  see  [Bei92a],  [Bei92b],  [Bei93],  the  Assert 
package  became  much  easier  to  use.  With  good  iterates  we  found  it  easy  to  build  assertion  tests  for  a 
variety  of  homogeneous  data  structures.  This  will  be  demonstrated  in  the  article  with  array  iterators.  With 
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just  two  types  of  array  iterators  as  tools  for  building  assertions,  we  found  we  could  easily  build  most 
assertion  tests  for  many  classical  array  based  algorithm. 

Just  as  our  fhistration  was  beginning  to  peak,  this  project  was  assisted  by  another  project  that  involved 
the  construction  of  a  repertoire  of  Ada  software  components.  Each  of  our  software  component  packagfts 
contained  appropriate  iterators  for  the  various  components.  Iterators  became  an  invaluable  tool  for  the 
construction  of  algcvithms  to  test  assertions  about  components.  With  this  in  hand  we  went  back  to  the 
prc4>lems  we  had  constructing  assertions  for  array  algorithms.  First  we  constructed  a  simple  package  of 
array  iterators,  then  used  these  iterators  to  construct  assertions.  The  result  was  a  dramatic  reaction  in 
the  amount  of  code  written  to  perform  assertion  testing. 

The  flnal  section  summarizes  the  results  contained  in  this  paper  with  some  practical  observation  and 
plans  for  future  spin-offs  from  this  project  The  practical  observation  is  that  the  use  of  iterators  in 
assertion  testing  provides  a  type  of  "proof-reading"  approadi  to  proving  the  correctness  of  a  program.  If 
two  proof  readers  come  to  the  same  omclusions  about  a  piece  of  text,  the  text  is  assumed  correct.  The 
noted  mathematician,  George  Polya,  wrote  an  article,  see  [Pot76\,  about  the  mathematics  of  proofreading. 
In  the  future  we  plan  to  analyze  the  use  of  the  Assert  package  in  light  of  Polya’s  article.  By  a  proof¬ 
reading  proof  we  mean  that  if  two  independent  pieces  of  code  produce  the  same  answer  there  is  a  higher 
degree  of  confidence  that  the  code  is  correct,  espedally  if  the  two  pieces  of  code  are  truly  independent 
To  some  extent,  the  use  of  independently  written  iterators  to  construct  assertion  tests  jx^ovides  a  reliable 
and  cost  effective  means  of  testing  assertions. 

Once  we  started  using  iterators  to  build  tests  for  assertions,  we  found  that  it  may  be  convenient  to 
build  a  repertoire  of  packages  of  small  pieces  of  code  to  support  a  collections  of  typical  asserticms  about 
the  structures  of  various  components.  We  see  the  new  nested  library  scheme  in  Ada-9X  as  a  desirable 
framework  for  the  packaging  of  assertion  testing  toots.  We  plan  to  proceed  with  this  project  when  we 
gain  access  to  a  Ada-9X  compiler.  With  Ada-9X’s  ability  to  nest  packages,  we  believe  we  can  use  this 
feature  to  build  collections  of  reusable  assertion  testing  tools  and  components. 


3.1  Tho  Assert  Package 


The  ASSERT  package  is  quite  simple  in  design.  The  specifications  for  the  assert  package  appear 
in  Figure  1.  A  natural  assumption  made  regarding  the  use  of  the  assert  package  is  that  clients 
understand  the  basics  of  program  correctness.  The  four  assertion  testing  procedures.  Precondition, 
Postcondition,  Invariant,  and  Assertion  are  essentially  identical.  The  only  difference  between  them  is  a 
unique  prefix  placed  by  the  procedure  in  front  of  the  output  requested  by  the  client.  The  implication  is 
that  the  client  uses  the  appropriately  named  procedure  when  requesting  an  assertion  test  and  uses  identical 
Prefix  strings  for  procedures  that  correspond  to  the  same  structure.  For  example,  given  the  statement 
sequence. 


Sum  :=  0; 

for  i  in  1  . .  n  loop 
SiUD  Sura  +  A(i}  ; 
end  loop  ; 
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Rgure  1  ASSERT  Specifications 


may  have  the  corresponding  assertions, 


Sun  t-  0; 

ASSERT. Precondition  (  Sun  >  Sun_0F  (A,  0), 

"Sun  loop",  "start",  "Failed"); 
for  i  in  1  . .  n  loop 
Sun  i*  Sun  +  A(i)  ; 

ASSERT. Invariant  (  Sun  *  Sun_OF  (A,  i), 

"Sun  loop",  integer' inage( i) ,  "Failed"); 
end  loop  ; 

ASSERT. Postcondition  (  Sun  *  Sun_OF  (A,  n), 

"Sun  loop",  "end",  "Failed"); 

where  the  prefix,  "Sum  loop"  appears  in  each  line  of  the  di^lay.  The  display  would  appear  as, 

PRE  :  Sun  loop  start 
INV  :  Sun  loop  1 

INV  :  Sun  loop  2 

INV  :  Sun  loop  3 

INV  :  Sun  loop  4 

INV  :  Sun  loop  5 

•  •  • 

POST:  Sun  loop  end 

The  prefixes  "PRE  t  ",  "iNV  t  ",  "POST:  ",  and"ASRTt  "  are  placed  at  the  beginning  of  the  line 
displayed  by  the  procedure  Precondition,  Invariant,  Postcondition,  and  Assertion,  respectively.  Combining 
the  assertion  prefixes  with  the  client  provided  prefixes  creates  a  display  format  that  is  easy  to  interpret 
For  example  the  nested  pair  of  loops  in  the  statement  sequence. 


Sun  0  ; 

ASSERT. Precondition  (Sun  »  Anatfer  (0), 

"Outer",  "start",  "Start  fail")  ; 
for  outer  in  1  . .  10  loop 

ASSERT. Precondition  (Sun  *■  Answer  (Outer-1), 

"  Inner",  "nest  begin",  "nest  fail")  ; 

■  for  inner  in  1  , ,  outer  loop 
Sun  :*  Sun  +  1  ; 

ASSERT . Invariant  (Sun  >  (Answer  (Outer 

-1)+Inner),  "  Inner", 
integer ' inage ( inner ) ,  "nest  fail")  ; 
end  loop  ; 

ASSERT . Postcondition  (Sun  «  Answer  (Outer), 

"  Inner", 

"nest  end"  6  integer ' inage ( outer ) , 
"nest  fail")  ; 

ASSERT . Invariant  (Sun  >  Answer  (Outer), 
"Outer", 

integer ' inage ( outer ) , 

"fail"  &  integer 'inage (outer)  )  ; 

end  loop  ; 

ASSERT. Postcondition  (Sun  *  Answer  (10), 

"Outer",  "start",  "Start  fail")  ; 

have  assertions  that  produce  the  display. 
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PRB  >  Outer  start 

PRB  :  Inner  nest  begin 

IMV  :  Inner  1 

POST:  Inner  next  end  1 

INV  :  Outer  1 

PRB  :  Inner  nest  begin 

IHV  t  Inner  1 

IMV  :  Inner  2 

POST:  Inner  next  end  1 

IMV  :  Outer  2 


Because  of  the  potential  veibosity  of  the  display,  the  package  has  two  gk^al  modes  and  two  display 
modes.  The  global  modes  are  oa  and  off.  The  di^lay  modes  are  referred  to  as  Al^ha  mode  and  ^ta 
mode.  The  package  displays  assertion  messages  cmly  when  the  global  mode  is  on.  No  messages  are 
displayed  when  the  global  mode  is  off.  When  the  global  mode  is  on,  if  the  display  mode  is  Alpha,  every 
time  an  assertion  testing  procedure  is  called  a  message  is  displayed.  In  Beta  mode  messages  are  di^layed 
only  when  a  test  fails.  By  selectively  using  the  global  on/off  modes  with  the  display  Alpha/Beta  modes 
clients  may  control  the  verbosity  of  the  display. 

The  usefulness  of  the  package  depends  somewhat  on  the  cleverness  of  a  clirat  in  performing 
meaningful  assertion  tests  along  with  useful  and  distinct  messages.  A  future  modification  of  the  package 
will  be  the  inclusion  of  a  Silent  display  mode.  In  Silent  mode  all  assertion  messages  are  placed  in  a  file, 
which  may  be  viewed  at  a  later  time. 


3.2  Package  Applications 

Building  an  assertion  testing  package  is  easy,  making  it  useful  is  another  story.  To  illustrate,  consider 
building  the  assertions  to  test  a  simple  algcxithm,  like  the  bubble  sort  illustrated  in  Figure  2.  A  set  of 
assertions  to  test  the  looping  conditions  for  the  bubble  sort  appears  in  Figure  3.  Fortunately,  the  tests  for 
all  the  assertions  may  be  aeated  using  a  single  function,  iB_sorted,  which  also  appears  in  Figure  3. 


procedure  Bubble_Sort  (A  i  in  out  lnt_Array)  la 
te^>,  bub  I  Integer  ; 
begin 

tio.Put_Llne  ('Start  sort')  : 
tio.PutJLine  ('first  preeond*)  ; 
for  index  in  1  . .  A'range'Iaet-1  loop 
bub  <-  index  ; 
while  (bub  >0) 

and  then  (A  (bub)  >  A  (bub-t-l))  loop 
teap  I-  A  (bub); 

A  (bub)  A  (bub+l)  ; 

A  (bub+1)  I-  teap  ; 
bub  I-  bub  -  1; 

end  loop  ; 
end  loop; 
end  Bubble_Sort  ; 

Figure  2  Bubble  Sort  Algorithm 


Figure  4  (X)ntains  a  partial  listing  of  sample  output  from  the  asserti<Mis  in  Figure  3.  This  simple 
example  demonstrates  one  of  two  problems  associated  with  using  the  assert  package,  its  propensity  for 
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rnaecioo  zs_Bort«d 

(A  T  Int_Arrayi 
start,  ~ 

rialab  I  inta9az  )  raturn  bpolaaa  la 
bagla  —  la_Sortad 

for  indax  In  (Start-fl)  ..  Flnlah  loop 
If  A(lndax-l)  >  A(Ii^x)  than 
raturn  falaa  ; 
and  If  t 
and  loop  ; 
raturn  trua  i 
and  la_8ortad  } 

procadura  Bul>bla_8ort  (A  i  la  out  Int_Array)  la 
tanp,  bub  i  Intagar  ; 
bagln 

tlo.Put_Llna  ('Start  aort')  ; 

ASSERT. PraCondltlon  (  Za_Sortad  (A,  1,  1), 

■Outar*,  "Start*,  "Start  arror*)s 
tlo.Put_Llna  ("first  praeond")  t 
for  Indax  In  1  ..  A' ranga' last-1  loop 
bub  I-  Indax  ; 

ASSERT. Praeondltlon  (Ia_Sortad  (A,  1,  Indax), 

*  Inaar",  "Start",  "Start  arror*)} 
whlla  (bub  >  0) 

and  than  (A  (bub)  >  A  (bub-t-l))  loop 
tanp  I-  A  (bub); 

A  (bub)  i»  A  (bub+l)  ; 

A  (bub-fl)  I-  ta^  ; 

bub  t-  bub  -  1; 

ASSERT . Invariant 

(  ls_Sortad  (A,  bub>l,  Indax^l), 

"  “innar", 

Intagar  *  Inaga  ( bub'*'  1 ) , 

"Invariant  arror*); 
and  loop  ; 

ASSOtT .  Postcondition 

(  Is  Sortad  (A,  1,  Indax'*!), 

*  "innar",  "Plnlsh",  "Finish  arror'); 

ASSERT.  Invariant  (  Is  Sortad  (A,  1,  ladax-t-l), 

"Outar",  "OK",  Intagar 'laaga( Indax)  ); 
and  loop; 

ASSERT . Postcondition 

(  Is_8ortad  (A,  1,  A'Ranga'last), 

"Outar",  "OK",  "and  arror"  ); 
and  Bubbla_Sort  ; 

Figure  3  Bubble  Sort  with  Assertions 


producing  enormous  amounts  of  output.  If  the  procedure  in  Rguie  3  was  siting  five  hundred  numbers, 
the  assertion  tests  would  produce  approximately  250,000  lines  of  output 

By  selectively  using  the  package’s  On/Off  switch  and  the  Alpha/B^  display  modes  a  client  can 
dramatically  reduce  the  amount  of  output  produced  by  the  package.  Since  the  major  concon  centers  on 
assertion  failures,  the  Beta  display  mode  is  normally  the  primary  intnest  of  clients.  In  Beta  mode,  (mly 
assertion  failures  produce  output,  a  system  that  is  mostly  correct  would  produce  very  little  output,  and  the 
ou^ut  that  is  produced  would  be  the  output  that  is  of  most  interest  to  clients. 
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c 


Figura  4  Sampto  Ou^pKit  for  Bubbto  Sort  Assortions 


The  secona  fundamental  problem  with  using  the  Assert  package  is  the  gmeral  i^oblem  of  creating 
assertions.  i*br  the  best  possible  results,  assertion  tests  should  be  developed  independently  of  the  package 
being  tested.  There  are  sound  formal  reasons  for  the  independent  develofmient  of  assertions.  The  fcumal 
reasons  are  addressed  in  Section  ?.  Informally,  it  is  desirable  for  the  independoit  developmoit  of  assertion 
tests  so  that  the  code  in  the  assertion  tests  is  as  distinct  as  possible  from  the  code  in  the  program.  The 
basis  for  the  assertion  tests  in  Figure  3  is  at  least  a  Function  whose  code  is  independent  of  code  in  the 
{procedure.  A  more  desirable  situation  would  be  to  have  as  much  code  as  possible  pre-written,  which  leads 
us  to  Section  ?. 


3.3  iterators  and  Assertions 

Many  times,  the  coding  effort  involved  in  building  assertion  tests  is  potentially  as  large  as  the  effort 
required  to  build  the  system  being  tested.  This  would  explain  why  assertion  testing  is  not  a  popular 
method  of  testing  the  correctness  of  programs.  This  difficulty  may  be  overcome  with  the  right  software 
development  tools.  One  family  of  tools  that  we  have  found  to  be  very  useful  is  the  family  of  iterates 
over  homogeneous  data  structures. 

Frequently,  assertions  center  on  verifying  relationships  that  hold  regarding  the  contents  (rf 
homogeneous  structures.  Often,  algorithms  to  test  assertions  may  be  accomplished  through  the  traversal 
of  a  structure  while  performing  simple  comparison  tests.  The  traversal  may  be  constructed  with  a 
predefined  iterator.  Fortunately,  in  our  environment  the  packages  for  all  homogeneous  data  structures 
include  collections  of  the  typic^  iterators  over  the  structure.  For  example,  binary  tree  packages  include 
should  include  breadth  first,  depth  first,  and  other  typical  iterators.  In  addition,  we  have  a  standard  array 
tool  package.  The  specifications  for  the  array  iterators  appear  in  Figure  5. 

When  it  comes  to  developing  assertions,  there  are  two  advantages  in  using  iterators  when  they  are 
available  and  appropriate.  The  first  advantage  is  that  iterators  can  dramatically  reduce  the  amount  of  code 
written  to  test  assertions.  A  second  advantage  with  iterators  is  that  the  traversal  code  for  the  structure 
exists,  and  may  be  presumed  to  be  correct,  hence  inaeasing  the  probability  that  the  assertion  test  is  valid. 

The  selector  version  of  the  step  and  bisection  array  iterators,  serve  as  the  basis  for  many  array 
traversal  based  assertions.  To  illustrate,  consider  the  coding  for  the  assertion  testing  function,  zs_8ort«d, 
in  Hgure  3.  It  is  composed  of  a  loop  to  traverse  the  part  of  the  array  being  tested  and  an 
structure  that  performs  the  actual  test.  Figure  6  illustrates  a  version  of  Xn_8ort«d  built  with  the  use  of 
an  iterator.  In  the  iterator  based  version  the  client  only  writes  a  procedure,  Ch«ck_OD«,  to  perform  a 
single  test  and  instantiates  the  iterator  with  that  test. 

The  use  of  iterators  actually  serves  two  purposes.  Beside  the  obvious  benefit  of  reducing  the  amount 
of  code  written  to  perform  the  assertion  tests,  basing  the  assertion  tests  on  iterators  makes  the  code  that 
performs  the  assertion  tests  dramatically  different  than  the  source  code  being  tested.  This  difference  helps 
provide  some  degree  of  independence  between  the  system’s  code  and  the  assertion  testing  code.  That 
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independence  helps  alleviate  some  of  the  concerns  that  the  assertion  testing  code  may  be  tainted  by  the 
system’s  code.  That  is,  the  group  writing  the  assertion  testing  code  may  have  a  tendmcy  to  echo  the 
system’s  code  while  writing  assertion  tests.  As  a  result  the  assertion  tests  could  contain  the  same  enors 
that  appear  in  the  actual  code.  By  writing  assertion  tests  in  a  di^erent  way,  building  them  on  top  of 
iterators,  there  is  greater  certainty  that  errors  existing  in  the  system’s  code  are  not  edioed  in  the  assertions. 

4  Estimating  The  Number  of  Undiscovered  Error 

After  testing  a  software  system  how  many  undiscovered  enors  still  remain?  After  a  certain  amount 
of  testing,  locating,  and  correcting  of  errors  can  the  testing  information  be  used  to  form  a  mathematically 
sound  estimate  of  the  number  of  undiscovered  errors?  This  paper  describes  a  statistical  framework  for 
making  estimates  about  the  number  of  enors  that  may  still  remain  in  a  software  system  as  well  as 
provirtog  measures  of  the  quality  of  the  testing  process.  This  paper  also  suggests  several  methodologies 
that  may  help  to  improve  the  accuracy  of  the  results  obtained  when  using  the  techniques  described  in  this 
paper. 
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function  ia_sort*<i 

(A  I  lnt_Array; 

Start,  ~ 

Finlah  I  Integar  )  return  boolean  la 

Anawer  t  boolean  t»  true  } 

procedure  Check  One 

(A  t  In  Int  Array  ; 

Index  I  In  poaTtive  ; 

Continue  i  out  boolean  / 

Anawer  >  In  out  boolean  )  la 

begin  —  Cbeck_One 
if  A(lBdex-l)  ^  A(Zadex)  tbea 
Ceetlaue  true  | 

elae 

Coutlaue  t*  falae  } 

Anawer  falae  } 

end  If  I 

end  Check_One  ; 

procedure  CheckJRange  la  new 

Array_Toola . Arr ay_Step_Selector 
(  Object_Type  m>  Integer  , 

Array_Range  >>  poaltlve  , 

Array~Type  ->  lnt_Array  , 

Paaa_Thru_Type  >>  boolean  , 

Proceaa  ~  >>  Check_One  )  ; 

begin  --  la_Sorted 

Check_Kange  (A,  Start+1,  1,  Flnlah,  Anawer)  ; 
return  Anawer  ; 

end  Ia_Sorted  ; _ 

Rgure  6  ls_Sorted  Using  An  Iterator 


Let  X  be  the  number  of  errors  Uiat  exist  in  a  software  system.  Two  teams.  Able  and  Baker, 
independently  evaluate  the  system.  As  a  result  of  their  independent  evaluation  Team  Able  found  A  errors 
and  Team  Baker  found  B  errors.  Let  C  represent  the  count  of  the  number  of  errors  located  by  both  teams. 
C  is  included  in  A  and  B.  Let  p  be  the  probability  that  Team  Able  locates  any  given  enor  and  9  be  the 
probability  that  Team  Baker  locates  any  given  error,  p  and  q  rq>resent  independent  probabilities. 

It  is  reasonable  to  expect  that  the  number  of  errors  located  by  Team  Able,  A,  approximates  pX,  the 
number  of  errors  Team  Able  is  expected  to  find.  Similarly,  B  approximates  qX,  the  number  of  errors 
located  by  Team  Baker,  and  C  approximates  pqX,  the  number  of  errors  located  by  both  teams.  This  leads 
to  the  following  estimate  for  X  the  number  of  errors  in  the  system, 

^  pX  qX  A’B 

■  ptfiC  c 

The  total  number  of  discovered  errors  is  A  B  •  C.  An  estimate  of  the  number  of  undiscovered  enors 
is 

X-{A*B-C)  - 

c 
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AB-AC-BC*C^ 

C 


c 


Estimates  for  the  values  p  and  q  are  of  interest,  they  produce  measures  of  the  quality  of  work 
performed  by  each  team.  The  measure  of  the  quality  of  the  wwk  perfmmed  by  Team  Able  is 


P 


qX  B 


The  measure  of  the  quality  of  work  performed  by  Team  Baker  is 


<7  = 


PQX_C 
pX  A 


To  illustrate  uses  of  these  estimates,  consider  the  independent  evaluation  of  a  software  system  by  two 
teams.  Able  and  Baker,  that  produces  the  values  30,  35,  and  25  fm  A,  B,  and  C,  respectively.  The 
estimate  for  the  total  number  of  errors  is  42.  The  number  of  errors  discovered  by  the  two  teams  is  30-f35' 
25  -  40.  The  estimate  for  the  number  of  undiscovered  errors  is  2!  Hnally,  the  measures  for  the  quality 
of  work  performed  by  teams  Able  and  Baker  are  25/35  s  71%  and  25/30  =  83%,  respectively. 

As  a  second  example,  suppose  the  independent  evaluation  of  a  software  system  by  two  teams  produces 
the  values  30,  35,  and  15  for  A,  B,  and  C,  respectively.  These  values  produce  an  estimate  of  70  for  the 
total  number  of  errors  in  the  system.  Since  30+35-15  =  50  orrors  were  discovered,  and  the  estimate  for 
the  number  of  undiscovered  errors  is  20.  The  quality  measures  of  the  two  teams  evaluating  the  software 
are  15/35  =  43%  and  15/30  =  50%. 

This  tedmique  is  based  on  work  by  Polya,  see  [Pol76],  on  the  probabilities  of  the  number  of 
undiscovered  errors  in  a  text  after  being  proofread  independently  by  two  proofreaders.  In  that  paper  Polya 
uses  probabilities  to  determine  an  estimate  of  the  number  of  undiscovered  mistakes  that  exist  in  a 
manuscript  after  the  manuscript  has  been  independently  evaluated  by  two  proofreaders.  To  what  extent 
can  this  approach  be  applied  to  software?  At  whidi  points  could  this  technique  be  applied  during  the 
software  system  life  cycle?  There  are  two  considerations  that  must  be  addressed  for  Polya’s  "proofreading 
approach"  to  apply  to  the  evaluation  of  software  systems.  One  is  the  relationships  that  exist  between 
problem  domain  of  the  software  syston  and  the  domain  of  use  of  the  system  by  the  groups  beta  testing 
the  system.  The  second  issue  is  addressing  whether  the  requirements  of  the  maftematical  foundation  are 
met  in  the  testing  process.  These  issues  are  addressed  in  the  next  two  sections. 
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4.1  Domains 


^plying  ]m)babilities  to  proofreading  is  relatively 
easy  when  compared  to  applying  the  same  approach  to 
estimating  the  number  of  errors  that  exist  in  a  software 
system.  Speciflcally,  in  the  case  of  proofreading  the 
work  domain  of  the  two  proofreaders  is  identical,  the 
same  manuscript.  With  large  complex  software 
systems  the  problem  is  complicated  by  a  collection  of 
domains,  llie  software  system  functions  over  the 
domain  of  the  problem  space  for  which  it  was 
intended.  Beta  testers  might  only  test  a  subdomain  of 
the  software’s  problem  dcnnain,  that  part  of  the 
problem  domain  that  is  of  interest  to  them.  For 
example,  assume  the  software  system  was  a 
spreadsheet  system.  Most  users  to  not  use  all  of  the 
features  of  a  spreadsheet,  they  concentrate  on  those 
features  that  are  useful  to  them  in  their  problem 
domain,  which  is  a  subdomain  of  the  spread^eet’s  capability.  Two  different  beta  testers  may  be  testing 
overlapping,  but  generally  unrelated  subdomains  of  the  software  system’s  domain,  see  Figure  7. 


Rgure  7  Incompatible  Beta  Testing 
Domains 


Assume  two  beta  testers  are  testing  a  software  system  and  there  tests  are  represented  by  Figure  7.  If 
the  software  system  developer  has  confidence  in  the  work  performed  by  the  beta  tester,  then  the  estimates 
p  and  q  helps  measure  the  relationships  between  the  subdomains  of  the  beta  testers.  If  ^  s  0,  then 
the  suMomains  of  the  beta  testers  do  not  overlap.  Up  <q^l,  then  the  subdomain  of  beta  tester  Able 
is  contained  within  the  subdomain  of  beta  tester  Baker,  llie  closer  p  and  q  are  to  one,  The  closer  the 
subdomains  of  the  two  beta  testers.  Figure  8  illustrates  an  example  where  two  beta  testers  are  testing  very 
similar  domains. 


The  values  p  and  q  must  be  used  carefully.  On 
one  hand,  if  a  software  developer  expects  a  beta  tester 
to  perform  a  good  job,  the  values  p  and  q  could 
provide  a  measure  of  the  relationships  of  domains 
between  beta  testers. 

On  the  other  hand,  if  a  software  developer  is 
confident  that  two  beta  testers  are  testing  similar,  or 
identical,  subdomains,  as  illustrated  in  Figure  8,  the 
values  p  and  q  may  be  good  measures  of  the  quality 
of  work  performed  by  the  two  beta  testers.  In  this 
case. 


Figure  8  Similar  Beta  Testing 
Domains 


(>i- 0(8-0 

c 


14 


is  an  estimate  of  the  number  of  errors  that  remain  undetected  in  the  in  the  beta  tested  subdomain  of  the 
system. 


4.2  Independence 


First  of  all,  the  results  are  estimates  and  must  be  carefully  analyzed  before  the  results  may  be 
interpreted.  Whether  the  statistical  foundation  of  these  calculations  is  sound  depoid  heavily  on  the 
evaluations  of  the  software  system  being  determined  by  the  two  teams  working  in  a  truly  independoit 
fashion.  The  statistical  computations  are  based  upon  the  {vobabilities  of  independent  events.  One  might 
question  whether  the  ability  of  the  team  to  determine  one  error  is  indepoident  of  their  ability  to  locate  any 
other  error.  Assume  that  error  i  may  be  located  with  probability  Pf.  Thai  p  is 


where  n(JO  is  the  number  of  errors. 


Ep, 

_  kX 

■  iKJO 


Intuitively,  the  more  errors  found  in  a  system,  the  lower  the  confidence  we  should  have  in  the  software 
system.  On  the  other  hand,  each  time  an  errcv  is  located  and  corrected,  without  introducing  a  new  error, 
the  software  system  is  closer  to  being  correct  The  obvious  question  is:  Just  how  close? 

The  approach  advocated  in  this  paper  suggests  a  methodology  for  obtaining  an  estimate  on  the  number 
of  errors  that  remain  in  the  system  and  evaluations  for  the  quality  of  testing  being  performed.  Since  the 
approach  produces  statistical  estimates,  there  are  a  variety  of  factor  that  can  adversely  effect  the  estimates. 
Two  factors  that  can  effect  the  results  and  a  way  of  producing  multiple  estimates  are  described  below. 

The  results  described  above  depend  upon  the  probability  of  occurrence  of  independent  events.  Thoe 
are  two  ways  in  whidi  independence,  or  the  lack  there  of,  may  effect  the  estimates  produced.  First,  it  is 
important  that  the  two  individuals,  or  groups,  performing  the  testing  do  it  in  an  independent  fashion.  If 
there  is  any  direct,  or  indirect,  communications  betweoi  the  two  testing  groups,  the  estimates  are  invalid. 
The  second  assumption,  over  which  we  have  no  control,  is  that  the  probability  of  a  particular  testing 
group  of  finding  any  givoi  error  is  independent  of  locating  any  other  error.  One  could  argue  that  once 
a  certain  type  of  en<x  is  recognized  in  a  software  system,  a  tester  might  devise  a  process  of  locating 
similar  errors,  hence  invalidating  the  independent  prc^ability  of  locating  errors. 


4.3  Beta  Testing  Equivalent  Domains 

It  should  be  noted  that  the  validity  of  the  estimate  of  the  number  of  undiscovered  errors  is  valid  only 
when  the  beta  tester  test  the  exact  same  subdonains  of  the  problem.  At  first  that  may  appear  to  be  an 
impossibility.  However,  if  assertion  testing  is  placed  into  ea^  program  where  the  results  of  the  assertion 
tests  are  reported  to  a  file,  the  file  may  be  analyzed  relative  to  the  beta  test  results  provided  by  a  testa. 
Now  the  errors  indicated  by  the  assertion  tests  may  be  measured  relative  to  the  errors  rqxvted  by  the  beta 
tester,  the  assertion  tests  are  performed  on  the  identical  domain  as  the  dcxnain  of  the  beta  testa,  hence 
the  estimates  of  the  undiscovered  errors  within  Uiat  subdomain  could  be  fairly  accurate. 
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4.4  Multiple  Estimates 

When  more  than  two  beta  testers  is  are  used  a 
collection  of  estimates  may  be  formed.  Assume  the 
beta  testers  are  testing  in  the  same  subdomain  of  the 
problem  domain  and  there  are  X  enors  in  that 
subdomain.  Assume  the  three  beta  testers,  y ,  fi ,  and  e 
locate  errors  in  a  software  system  with  probabilities  p, 
q,  and  r,  respectively.  If  A  is  the  number  of  enors 
located  by  y ,  ^  is  the  number  of  errors  located  by  fi , 
and  C  the  number  of  enors  located  by  e.  Let  D  be 
the  number  of  enors  located  by  both  y  and  6 ,  £  be 

the  number  of  enors  located  by  both  6  and  e,  £  be  the  number  of  enor  located  by  both  Y  and  and 
G  be  the  number  of  enors  located  by  all  three,  then 

A  - pX,  S  -  qX,  C-rX,  D- pqX,  E  -  qrX,  F -prX,  and  G  -pqrX. 

There  are  flve  estimates  that  can  be  made  for  X, 

ABG-G  ^  BmC  ^  D  E'F 
D'EF  '  D'  E  '  F  ' 

and  three  estimates  each  for  p,  q,  and  r.  The  estimates  for  p  are 
be  obtained  for  q  and  r. 

With  three  or  more  beta  testers  one  may  use  the  results  to  produce  multiple  estimates.  These  results 
may  be  further  analyzed  for  consistency  between  the  beta  testers.  Our  experience  indicates  that  with 
multiple  beta  testers,  one  can  first  use  the  results  of  the  initial  enor  analysis  to  eliminate  results  that  are 
inconsistent  to  remove  certain  results  from  further  consideration,  then  apply  the  approach  described  above 
to  the  remaining  results. 

5  Finite  State  Automata 

It  is  desirable  to  introduce  flnite  state  automata  early  in  the  computing  curriculum.  Not  only  is  it  an 
important  theoretical  topic,  but  it  is  a  fundamental  design  topic.  In  design,  it  is  used  to  provide  broad  high 
level  design  characteristics  of  systems.  It  also  plays  an  important  role  in  object  oriented  design,  where 
state  transitions  describe  the  state  and  change  in  states  of  (Ejects  in  various  object  classes. 

We  introduced  finite  state  automatons  (FSAs)  as  a  theoretical  topic  and  made  extensive  use  of  CASE 
tools  as  a  means  of  drawing  state  transition  diagrams.  We  found  three  excellent  CASE  tools  that  freshman 
found  easy  to  use.  They  are  Open  Select,  Rationale  ROSE,  and  Weilan’s  LeCASE.  Along  with  the  CASE 


G* 


W%  ^  ff 

— ,  — ,and  — .  Similar  estimates  may 
EEC 


Figure  9  Identical  Subdomains 
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tools  we  also  discussed  methods  of  implementing  FSAs  in  prt^ramming  languages.  We  concentrated  on 
two  schema  for  implementing  FSAs,  one  using  a  state  transition  table  and  the  second  as  a  functimi. 

Besides  the  two  methods  mentioned  above,  we  also  used  a  simulator,  described  in  Section  6,  to 
simulate  FSAs.  One  lab(M'atory  assignment  and  one  software  develojmient  assignment  were  givra  to  the 
class.  The  laboratory  assignment  used  the  simulator  to  build  a  madiine  that  recognized  regular 
expressions.  For  the  laboratory  assignment,  the  student  were  given  a  relatively  simple  task,  like  build  a 
simulator  that  recognized  all  strings  of  zeros  and  one  where  the  number  of  zeros  was  divisible  by  five. 

The  software  development  assignment  requires  the  use  of  the  FSA  simulaUH',  building  a  graphic 
representaticm  using  one  of  the  CASE  tools,  and  implementing  the  FSA  in  Ada  and  testing  the 
implementation. 

The  FSA  simulator  is  actually  a  special  case  of  the  Turing  Machine  Simulator  deso'ibed  in  the  next 
section. 


6  Turing  Machine  Simuiator 

We  introduced  turing  madiines  in  the  CS  2  course,  the  second  semester  fi-eshman  computing  course. 
Turing  machines  were  introduced  as  part  of  a  software  development  example.  The  introduction  was  d(»e 
with  an  object  (wieated  flavor  by  first  discussing  the  component  classes  that  make  up  a  turing  machine 
simulator:  Tape  class.  Finite  State  Class,  Transition  controlled.  The  transition  controller  obtained 
information  from  the  other  objects,  tape  objects  and  finite  state  object,  determined  the  next  transition,  then 
sent  a  message  to  each  object  informing  it  of  its  change  in  state  (status). 


6.1  Overview 

Besides  the  description  of  a  turing  madiine  and  its  operations,  the  problem  discussed  the  issues  of  user 
interfaces  were  discussed.  The  program  presents  a  turing  machine  simulation  by  illustrating  the  movement 
of  the  tape  ao’oss  the  screen  and  indicating  the  state  transitions  as  they  occur.  The  simulator  had  user 
definable  controls.  A  user  has  the  following  opticxts: 

a.  Single  stepping  through  a  simulation. 

b.  Speeding  up  the  single  step  option  with  an  ability  to  perform  a  fixed  number  of  steps  before 
halting  the  simulation. 

c.  Going  to  continuous  simulation  mode.  Once  in  this  mode,  the  simulator  may  not  be  halted. 

The  simulator  also  includes  a  step  counter.  The  user  may  define  a  step  limit.  The  limit  is  used  to 
automatically  terminate  Ihe  simulator  when  the  limit  is  exceeded. 

The  simulator  terminates  when  either  when  the  step  counter  exceeds  the  limit,  or  when  no  transition 
exists  for  the  given  state/symbol  pair. 
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6.2  Construction 


The  simulator  is  put  together  as  a  collection  of  intmelated  packages.  The  system  is  oanposed  of 
three  packages  and  a  driving  procedure, 

a.  The  tm_tape  package 

b.  The  tmjstate  package 

c.  The  tm_madiine  package 

d.  The  tm  procedure 

The  madiine  is  entirely  encapsulate  in  the  tmjnachine  package.  As  sudi,  the  turing  machine 
simulator  may  be  used  with  other  programs  that  may  require  the  use  of  a  turing  madiine  to  porform  part 
of  its  task. 

The  tm  procedure  obtains  the  name  of  the  file  that  contains  the  machine  being  simulated,  calls  the 
machine  simulator,  and  passes  to  it  the  name  of  the  file  and  the  simulation  parametm. 

The  tmjtape  and  tmjstate  package  completely  encapsulate  tapes  and  states  in  an  object  oriented 
fashion.  That  is,  states  and  tapes  are  entirely  encapsulated  within  eadi  padcage,  including  the  infmmation 
each  tape  and  state  must  know  to  display  themselves. 

The  tm  package  instantiates  the  tmjmadune  with  the  type  of  machine  desires,  a  finite  state  auunnaton, 
or  a  one,  two,  or  three  tape  turing  machine.  In  turn.  The  tmjnachine  instantiates  the  tmjstate  package 
and  the  tmjtape  package.  In  the  case  of  finite  state  automatons,  we  made  a  special  versicm  of  tmjnachine 
that  restricts  the  tmjtape  to  a  one-way  read-only  tape,  and  simplifies  the  user  description  of  finite  state 
automata. 


6.3  Use 

Users  define  turing  madiines  by  cmnpleting  taring  tables.  The  tables  are  placed  in  an  ASCII  file, 
which  is  prepared  before  running  the  simulator.  To  assist  users  in  defining  turing  machines,  the  simulator 
accepted  ASCII  files  with  one  state  transition  per  record.  There  are  four  record  formats: 

a.  Comment  records  begin  with  a 

b.  The  first  recixd  in  a  sequence  of  records  associated  with  a  state  simply  contains  the  state  name, 

oid_state 

c.  The  transitions  for  a  specific  state  follow  the  record  with  the  state  name,  one  per  record,  with  the 
format, 

currentjymbol  next_state  new_symbol  headjnavement 

d.  A  blank  record  terminates  the  transitions  for  a  state. 
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The  old_state  and  next_state  were  strings  of  up  to 
eight  diaracters  in  length.  The  current  symbol 
and  newjsynUxjt  were  any  printable  ASCII 
diaracter,  except  which  has  a  special  meaning. 
The  headjttovements  are  *<’,  ot  whidi 
indicate  that  the  read  write  head  moved  left, 
remains  stationary,  or  moves  right,  respectively. 
The  symbol  is  a  "DONT  CARE”  indicator. 
That  is,  when  it  appears  in  the  place  of  the 
current _pate  or  current  jytnbol  it  means  the  value 
of  this  object  may  be  anything.  In  the  next_state 
or  newjyndml  positimi  it  means  keep  the  currait 
value.  Since  the  state  transition  table  is  read  from 
top  to  bottom,  DON’T  CARE  indicators  should 
appear  after  other  state  transitions  that  would 
override  them. 


—  A  ttio  tape  turlng  aachlne 

—  That  duplicates  the  atring  of 

—  xeroa  and  ones  bracketed  by 

—  dollar  ayabols  on  to  the  2nd  tape 
start 

—  Start  copies  the  first  $ 

$  -  er  $  >  $  > 

ar 

—  This  state  copies  the  rest  of  the 

—  symbols  to  the  second  $ 

0  -  mr  0  >  0  > 

1  -  mr  1  >  1  > 

$  -  HALT  $  -  $  - 


Rgura  10  Turing  Tablo  Example 


The  system  also  allows  users  to  place  comments  in  the  state  transition  tables.  Comments  may  be 
placed  in  line,  after  a  state  transition,  or  are  indicated  by  beginning  a  line  with 


7  Generalized  Towers  of  Hanoi 

The  classical  Towers  of  Hanoi  Problem,  see 
Figure  11,  is  a  game  involving  n  disks  and  three 
spindles.  The  diameter  of  eadi  disk  is  unique, 
llie  object  of  the  game  is  to  move  the  stack  of  n 
disks  from  the  spindle  containing  the  disks  to  a 
spedfled  target  spindle.  The  disks  must  be  moved 
one  at  a  time  by  removing  any  disk  from  the  top 
of  a  stack  on  one  spindle  to  another  spindle.  A 
disk  may  be  placed  on  another  spindle  only  if  the 
spindle  is  empty  or  if  the  disks  on  the  spindle  are 
Imger  than  the  disk  being  moved.  This  problem 
is  employed  as  an  example  in  a  number  of  mathematics  and  computing  courses  to  demonstrate  recursion 
or  algorithm  measurement  A  fairly  complete  and  traditional  presentation  cm  the  Towers  of  Hanoi  appears 
in  [Knu??]. 

The  Towers  of  Hanoi  problem  is  frequently  used  in  computing  courses  as  a  problem  whose  solution 
involves  a  non-trivial  use  of  recursion.  For  n  >  1  the  algorithm  fm  moving  n  disks  is  described  as  a 
recursive  three  step  process,  as  illustrated  in  Figure  12: 

Step  1:  Recursively  apply  this  algorithm  to  move  n-1  disks  from  spindle  A  to  spindle  B  using  spindle  C 
to  assist  in  the  process. 

Step  2;  Move  the  one  disk  on  spindle  A  to  spindle  C 

Step  3:  Recursively  apply  this  algorithm  to  move  the  n-1  disks  from  ^indle  B  to  spindle  C  using  spindle 
A  to  assist  in  the  process. 


Figure  11  Towers  of  Hanoi 
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Implementations  of  this  algorithm  in  recursive 
programming  language  appear  in  a  number  of 
programming  language  and  CS  1  texts,  including 
[],  [],  [].  Figure  13  contains  a  version  of  the 
solution  written  as  a  procedure  in  Ada.  This 
procedure  uses  a  screen  display  package  that 
visually  displays  the  disk  movements  as  they  are 
made. 

procedure  tower8_of_hanoi 
(  f rom_spindle , 
help_spindle, 

_ to_8pindle _ :  in 

Figure  13  Sample  Towers  of  Hanoi 
Program 


Let  H(n)  be  the  minimum  number  of  moves 
required  to  solve  the  Towers  of  Hanoi  problem 
with  n  disks.  Using  induction  it  can  be  shown 
that  H(n)  =  2"-/. 


Rgure  12  Recursive  Solution 

There  are  two  obvious  variations  of  the  tO  the  Towers  Of  Hanoi 

Towers  of  Hanoi  problem,  suggested  in  [Knu??J. 

One  variation  is  that  the  disks  are  not  all  different, 
several  disks  may  be  identical.  A  second  variation 

is  to  solve  the  problem  with  more  than  three  spindles.  A  four  spindle  version  of  the  Towers  of  Hanoi 
problem  is  used  by  several  of  our  computing  faculty  as  a  software  development  assignment  to  test 
students’  knowledge  of  recursicxi.  We  refer  to  the  four  spindle  version  of  the  Towers  of  Hanoi  problem 
as  the  Towers  of  Saigon. 


7.1  The  Towers  of  Saigon 


Independently,  two  faculty  had  used  the 
Towers  of  Saigon  as  a  programming  assigmnent 
In  both  cases,  students  were  required  not  just  to 
construct  a  correct  program  but  to  evaluate  their 
programs.  The  programs  written  by  students 
produced  a  large  variety  of  timing  results.  Several 
faculty  analyzed  these  results.  This  led  to  an 
analysis  of  the  various  solution  strategies 
implemented  by  the  students. 


A  B  C  D 


Figure  14  Towers  of  Saigon 
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Students  employed  Two  basic  solution 
strategies.  These  strategies  evolved  from  specific 
suggestions  made  by  the  two  faculty.  We  refer  to 
these  two  soiution  strategies  as  the  n-2  strategy 
and  the  split  strategy.  One  faculty  member’s 
suggestions  led  to  the  n-2  strategy,  the  other 
faculty  member’s  suggestions  led  to  the  split 
strategy.  Figure  IS  illustrates  the  n-2  recursive 
strategy.  In  the  n-2  strategy  a  tower  of  n  disks,  n 
>  2,  is  moved  in  five  steps: 

Step  1:  Recursively  use  this  five  step  algorithm  to  move  n-2  disks  to  ^indle  B. 

Step  2:  Move  one  disk  from  spindle  A  to  spindle  C. 

Step  3:  Move  the  last  disk  from  spindle  A  to  spindle  D. 

Step  4:  Move  the  disk  on  spindle  C  to  spindle  D. 

Step  5:  Recursively  apply  this  five  step  algorithm  to  move  the  n-2  disks  on  spindle  B  to  spindle  D. 

When  n  =  i,  the  single  disk  may  be  move  to  the  appropriate  ^indle.  When  n  =  2,  the  two  disks  may 
be  moved  to  the  appropriate  spindle  in  three 


The  second  strategy,  the  split  strategy,  makes 
specific  use  of  the  Towers  of  Hanoi  (3  spindle) 
algorithm.  With  split  strategy  a  number  K 
dependent  on  n,  is  selected.  This  strategy 
employs  a  three  step  process: 

Step  1’:  Recursively  apply  the  split  algorithm  to 
move  n-k  disks  from  spindle  A  to  spindle  C. 

Step  2’:  Apply  the  Towers  of  Hanoi  soluticm  to 

move  the  k  disks  from  spindle  A  to  spindle  D  using  spindle  B.  Note  that  spindle  C  cannot  be  used 
because  the  disks  on  spindle  C  are  smaller  than  the  disks  being  moved  during  this  step. 

Step  3’:  Recursively  apply  the  split  algorithm  to  move  the  n-k  disks  from  spindle  C  to  spindle  D. 

Most  students  applied  the  split  strategy  by  dioosing  k  =  pn  for  some  p,  0  <=  p  <  I.  Typical  values 
selected  for  p  were  i/2, 1/3,  and  1/4.  Regardless  of  the  dioice  made  for  p,  for  large  values  of  n  the  split 
strategy  clearly  out  performed  the  n-2  strategy. 

Several  faculty  began  experimenting  with  the  split  strategy  using  various  functions,  k=J(n),  for 

selecting  k.  Independently,  two  faculty  found  the  choice  of  ^  ‘  ^  to  be  substantially  better  than  other 
functions  that  were  attempted.  This  lead  to  an  interest  in  determining  the  best  possible  split  strategy 
solution,  or  possibly,  the  best  solution  for  all  possible  strategies. 

Observe  that  the  Split  Strategy  encapsulates  all  possible  strategies.  For  example,  the  n-2  strategy  is 
an  example  of  the  Split  Strategy  with  k  =  2.  Regardless  of  the  strategy  that  one  might  adopt  to  solve  the 
Towers  of  Saigon,  that  strategy  must  included  the  building  of  a  tower  of  size  it  on  an  intermediate  spindle 
while  the  remaining  disks  are  moved  to  the  target  spindle  using  the  remaining  three  spindles. 


Figure  16  The  Towers  of  Saigon 
Spin  Soiution  Strategy 


Figure  15  The  Towers  of  Saigon 
n-2  Soiution  Strategy 
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7.2  A  Minimum  Move  Strategy  for  the  Towers  of 
Saigon 

Let  H(n)  be  the  minimum  number  of  moves  required  to  solve  the  Towers  of  Hanoi  problem  with  n 
disks.  Let  S(n)  be  the  minimum  number  of  moves  required  to  solve  the  Towers  of  Saigon  problem  with 
n  disks.  The  solution  f(Mr  moving  n  disks  in  the  Towers  of  Saigon  may  be  viewed  as  finding  the  c^Himum 
split  location,  k,  so  that  n-k  disks  are  moved  using  a  four  spindle  algorithm  to  (me  of  the  two  assisting 
spindles,  then  moving  the  lower  k  disks  using  a  three  spindle  (Towers  of  Hanoi,  H(k))  algorithm  to  the 
final  spindle,  and  then  moving  the  n-k  disks  to  the  flnal  spindle  using  a  four  spindle  algorithm.  It  is  well 
known  that  the  minimum  number  of  moved  for  the  three  spindle  Towers  of  Hanoi  problem  with  k  disks 
is  2*-7.  Qearly, 

S(n)  =  0,  for  n  =  0, 

=  1,  for  n  =  1, 

=  2  S(n-k)  +  H(k),  for  some  k,  0  <  k  <  n,  otherwise. 

We  wish  to  determine  a  formula  for  k  in  terms  of  n  that  will  determine  S(n),  call  it  g(n),  i.e.,  our  best 
choice  is  k  =  g(n).  Let  AS(n)  =  S(n)  >  S(n-1).  We  wish  to  minimize  AS(n).  Observe  that 

AS(n)  =  2  S(n-g(n))  +  -  1  -  (2  S(n-l-g(n-l))  +  2*“-»  -  1). 

That  is, 

AS(n)  =  2  [S  (n-g(n))  -  S  (n  - 1  -  g(n  - 1))]  +  2*‘'>  -  2*‘-‘>. 

If  g(n)  =  g(n-l)  then 

AS(n)  =  2[S(n-g(n))-S(n-l-g(n))]. 

If  g(n)  =  g(n-l)  +  1  then 

AS(n)  =  2  (S  (n-[g(n-l)+l] )  -  S  (n  -  1  -  g(n  -1)))  +  2*‘-‘>*‘  -  2^"-‘>  =  2*‘-‘\ 

It  is  clear  that  to  minimize  AS(n),  we  wish  to  keep  g(n)  =  g(n-l)  until 
2[S(n-g(n))  -  S(n-l-g(n-l))]  >  2--». 

Hence  g(l)  =  g(2)=l,  g(3)  =  g(4)  =  g(5)  =  g(l)  +  1,  g(6)  =  g(7)  =  g(8)  =  g(9)  =  g(5)  +  1,  and  so  forth. 
That  is,  g(n)  remains  Hxed  one  time  more  in  each  subserpient  subsequence  of  values  of  g(n).  That  is,  g(n- 
1)  is  the  greatest  integer  such  that 

iiH- 
M 
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Thus  g(n-l)  satisfies  and  by  the  quadratic  fwmula, 

2 

2 


The  sequence  AS(n),  s  s  1,  2,  3, is  the  sequmce 


and 


[a^}=  1,2. 2,  4.  4.  4. 8. 8.  8,  8. 


a. -2  * 


7.3  Observation 

Acccvding  to  a  tale,  a  group  of  monks  made  a  deal  with  God.  He  would  solve  a  64  disk  version  of 
the  Towers  of  Hanoi  at  the  rate  of  one  move  a  second  before  He  would  destroy  the  wcnld.  At  that  rate 
the  world  would  be  destroyed  in  584,542,046,091  years.  If  the  mmiks  would  have  made  the  same  (kal 
vidth  God  using  64  disks  and  4  spindles,  the  world  would  have  come  to  an  end  in  193  da)rs!  What  a 
difference  a  spindle  makes. 
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8  Software 

All  the  software  that  was  developed  through  this  grant  has  been  placed  in  the  PAL  (Public  Ada 
Library).  Portions  of  the  software  have  also  been  processed  with  static  logical  analyzers  and  modified  to 
conform  with  these  analyzers.  For  omnpleteness,  the  listing  of  the  packages  and  systons  developed 
through  this  grant  are  included  below. 
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—  Voot^oond  X  it  Condition  tlioa  dioyloy  Tron.Mooooys 
oloo  dinnUy  rolno.Naooofo  t 
•»  oniono  I  initod  by  oorcont  oywotiny 

■odo 


prooodoKO  Xnonriont  (  Condition  x  boelooa  i 
yrofis  X  ttriad  } 

ftoo_llnnn«do  t  Stciny  $ 
rnioo.fiMOoyo  i  dtrind  )  i 


— -  9so*»aond  I  Mono 

**  boot  oond  I  it  Condition  tbon  dioyioy  Txoo.Mooooyo 
oloo  dionloy  roioo.Hoooo^o  i 
ttolooo  Uni  tod  by  eoroont  oyorotiof 


poooodnoo  Aooortion  <  Condition  x  boo  loon  t 
bxoflji  X  ttxiny  } 

Tmo.Noooodo  X  Ctoiod  I 
roloo  Woooo^o  I  String  )  } 


btOooond  X  Mono 

••  boot  oond  x  if  condition  tbon  diopioy  ymo.Noooofo 
oloo  dionioy  roloo.Mooooyo  i 
oniooo  linitod  by  ooorront  oyoootiny 

■odo 


brooodoco  boto^Nodo  i 


—  bro  oond  i  bono 

—  boot  oond  t  biooo  pooboyo  in  blybo  Nodo 

—  Conont  t  In  boto.Nodo  if  tbo  pookiyo  io  tornod  *Qn*, 

only  tbo  boloo.Nooooyo  io  pcintod  obon  tbo 

—  oondition  boiny  tootod  by  on  oooostion 
prooodoco  foilo« . 


broeodoro  blpbo.Modo  t 


—  boot  oond  I  biooo  poeboyo  in  blpbo.Nodo 

—  Connont  t  Xn  blpbo  Nodo  if  tbo  p^boyo  io  tornod  *0n*» 

oitbor  tbo  Troo.Nooooyo  of  tbo  boloo.Nooooyo 
io  printod  oo  OMb  oooortion  toot  prooodxiro 
io  onlUd. 


brooodoro  Off  ; 


bro  oond  s  bono 

—  boot  oond  t  Oioployiny  of  oooortiono  io  tominotod 


*-  bro  oond  X  bono 

—  boot  oond  i  Dioplnyiny  of  ooxMrtiono  eontinnod  dopoadiny 


brooodoro  eleoo  i 
ond  booort  t 


■oin  X  Mnin  bifiteb  Typo  x>  on  i 

booboyo.Nodo  x  bookoyojlodo.Typo  x*  blpbo  x 

bioplny_bilo  X  foat_XO.bilo_Typo  i 

—  yonorio 

Typo.Nooooyo  x  otriny  } 

••  prooodoro  booortion^Voot  (  Condition  x  booloon  i 

—  brofin  I  Otriny  i 

Tmo.Mooooyo  i  Otriny  i 

boloo.Hooooyo  i  Otriny  )  x 

prooodnro  booortion.Toot  (  Condition  i  booloon  i 
typo  Nooooyo  x  otriny  ; 
brofin  1  otriny  t 

Trno  Nooooyo  x  Otriny  x 
Poloo.Mooonyo  t  Otriny  )  io 

boyin  —  booortion  toot 

font  XO.bvt  Uno  (*booort*)  x 
if  Moin  •  on  tbon 

^  tnift  XO.bot  Idno  (‘Moin  on”)  x 
if  rrmiiitiTrTi  tbon 

toot  XO.bnt  bino  (‘Condition  trno*)  i 
if  booEoyo.Hodo  •  blpbo  tbon 
^  tont.XO.bnt^Xdno  (‘blpbo*)  x 

bont.io. bnt.Lino 

(  Dioploy  PilOi  Typo  Mooooyo  i  *  x  *  A  brofin  & 
‘  ‘  A  Trnojtooooyo)  x 
ond  if  x 

oloo 

Tont_io .  bnt.Xdno 

(^Dioploy  bilo,  Typ»_Mooooyo  A  ‘i  ‘  A  brofin  A 
*  *  A  boloo  Nooooyo)  X 
•ad  ii  I 
•ad  U  > 

•ad  JLaaartiMi_(Mt  i 


~  graoadaia  traoaadittca  la  atM  ••••rliaa_Ti»at  <*tn*)  i 

—  pcosadoxa  teatoaadltlea  la  aaw  aaaaxtlaa_*aat  (*IOdr‘)  i 

..  fraoadm  lavaclaat  la  aav  aaaartlaa_Taat  (*!■•*)) 

—  paosadaxa  aaaaxtlaa  1#  aaw  Maartloa.taat  ( 'HMtOt' )  i 

■aasadaxa  traaaadltlaa  (  Csadltlea  i  baolaaa  i 
»Ta(la  I  ttrlat  i 

(nia.Naaaayt  i  atalaf  ) 
ralaa_llaaa>9»  i  (tela*  )  la 

bafla  ••  yrawiadtHiia 
booortion  Toot 

<Caadltiaa.  'mi',  Vxafla,  TrBa_liaaaa9a,  ralaa.maaaga )  ) 
•ad  graoaadltiaa  | 

pgeaadaxa  lanrlaat  (  Coadltloa  i  kaolaaB  | 

mfla  >  atrlaf  i 

(raa  !!•••■»•  i  stclatr  i 

r«laa_llaaa«»a  >  •txla«  )  la 

hayla  —  laTatlaat 
booortion  Toot 

(Condition,  ‘Xbb*,  brofin,  Trno.Nooooyo,  Poloo.Mooooyo)  x 
ond  Xnooriont  x 

prooodoro  bootonndition  (  Condition  x  booloon  x 

brofin  I  itriny  x 

Tmo^wooooyo  x  otriny  r 

roloo.Noonoyo  x  btriny  )  io 

boyin  bnotoonditinn 
booortion  Toot 

<CaadltT<ia,  'MdT',  rrafla,  Txaa_Maaaa9a.  ralaa_Naaaa9a)  i 
•ad  faataaadltlea  ) 

pceeadara  Jkaaaxtlaa  (  caadltlaa  i  baelaaa  > 

Vrafla  i  atrlaf  i 

Traa_Naaaafa  i  Stxlaf  | 

ralaa.Naaaafa  i  atrlaf  )  la 

bafla  —  aaaartlaa 
booortion  Toot 

(ConditTon,  *bO«T*,  brofin,  Tmo.Nooooyo,  boloo.Nooooyo)  i 
ood  booortion  x 


with  Tont_XO  I 

pookoyo  body  booort  io 

typo  Noin.Owiteh.Typo  io  (on,  off)  x 
typo  boekoyo.lledo.Typo  io  (blpbo,  boto)  x 


brooodoro  Boto.Nodo  io 

boyin  —  botojiedo 
boekoyo  Nodo  t«  boto  t 
ood  boti.Nodo  i 
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**alMf*,llad*  Alfh*  i 
md  dIfSa.aod*  i 


yrniwdBra  ia 

bafia  —  off 

Haia  !•  aff  i 
•ad  Off  I 

VKooadara  Oa  ia 

baaia  —  Oa 

Haul  t«  oa  t 
•ad  Oa  1 

noeadnc*  clas*  ia 


**■  ClO## 

fiwt.XO.CloM  (Di«pX«y_ril«)  I 
•ad  CXq««  I 

bafiji  •-  AMac% 

Taxt.xo.opra  <DlapUy  Plla,  TaKt_IO.oiit_flU,  ’DlUUUf.MC*)  i 
—  Ti>t_ZO.Op*«  (Dlaplay.rlla,  T»xt_I0.oat_flla,  ‘OOBi*)  > 


8.2  Turing  Simulator 

8.2.1  The  Procedure  tm 


~  Molti  Tm  T»iB«  WMhiiM  ■iMl.tet 
~  Th.  aianlatax  oT.»ta.  oa  .  oa.  aay  iaflalta  tm- 

—  Tlae.  .tata  traasltioa  tabla  in  a  data  fila  oaiag  tt. 

—  (ollaHiBf  tuB  xaoard  (oaaata 


—  tajabol  l..n>  «a«t_atata»  t.Ba«t_ajahol>  4Mad_aMn  l..n> 

~  A  <atata_naaa>  tacnrd  ia  tolUMad  hf  aaa  tranaitloa  taoard 
«  tot  aaoh  atata  txaaaitina.  Tha  *lM.d^aoa»>  la  a  *<* ,  nr 

—  a  ’>'  to  indloata  tkat  tba  kaad  la  to  aom  loft,  atay  ia 

—  poaltioa,  or  aooa  rifkt  raaBaotioaly-  th.  aat  of  atata 

—  tranaitieaa  ia  taraiaatad  «dth  a  raoord  ooatalatat  a 
~  Thara  ara  two  typaa  of  tilda  rooord,  althar 


—  -  <Baat  atata>  <Baw  ayabeia  •<haad_ao*a> 

~  tha  aaooad  tyaa  of  rooord  ia  a  oatek  all  aat  of  traaaitiaaa. 
~  That  ia,  a  tiid.  raoord  iadioataa  tka  traaaitiaaa  for  tkia 

—  atata  for  ail  othar  atata  aymi  palra  aot  liatad 

~  Stataa  ara  indioatad  by  a  a.qaaaoa  of  1..12  aoo  blank 

—  ekaraetora 


with  TBriapL.ltaohtao_»ia  i 
with  ■triag_aaaaaar  i 

with  iataTBr_toat  ie,  TOBt_IO,  feraan_10  t 


paokara  tio  raaawaa  Taitt_<0  t 
paekapa  iio  raaawaa  iataptr_taxt_lo  > 
paokap.  aio  raaawaa  aoraaa.XO  i 
paokapa  a  a  ia  now  (trlnp_teaaaar  t 


aobtypa  Aotaal  Tapa_Aaapa  ia  poaltioa 
typo  paadiiaajuray  ia 

array  (Aotual.Tm-*"**)  « 


raapa  t-.i  ) 
atrlap 


( 


lM_of_Tapaa  i  Aotaai_Tapa_*anpa  it 


■aadar  i  Baadliaajkrray  !•  ( 

Oil  TAPB  TOKIkP 
a  1.  A  T  0  a  *, 

*  T«0  TAPI  TOaXIP 

0  L  A  T  o  a  *, 

'  Tlall  TAPI  Tuaxip 
M  U  I  A  T  O  a  I 


N  A  e  a  X  I  I 
a  A  c  I  X  I  I 
M  A  C  I  X  I  I 


•  X  N 
a  X  N 

•  X 


paokap.  TM  ia  now  Tariap_Haehina_liw 
(lo.Ot  Tapaa  •>  lo.Of  Tapaa, 
Haakiaa_aow  ->  y.S«ao_of_Tapat, 
Naekijia'coL  o>  ys, 

IT  Bow  “»  S+S*lo_Of_Tma. 

ItIcoI  •>  40  )  I 


aabtypa  Tapa.Baapa  ia  1M.Tapa_aaapa  i 


PiXa  law.  i  atrlap  (1..I0)  ; 
P_Biia  ■  aatarai  ; 


■tata 

a_iiao 

■t_Tok 

Tapa 

Nax.ltapa 

lof 


t  1N.atata_lawo_ltriap  ) 

■  aatoral  | 

I  TM . Aotiowjlaoord  ; 

I  BI.Tapa_XBitJU:ray  | 

■  aatarai  ) 

I  atrlap  (i..l0)  } 

I  aatarai  | 


proeadara  Moaaapa  (Mop  i  atrlap  )  la 


laf  I  atrlap  (1..40)  ; 
a_l  I  aatarai  I 


bapia  —  Maaaapa 
alo.Pntl(Map,  20,  1)  ; 
aio.Patl  ('<or>  to  oontlaa.*,  21,  1)  i 
tio.Oat.lino  (laf,  ■_■)  I 

and  Maaaapa  t 


proeadara  laadiiaa  ia 
bsyiA  -o  esftdl 

•loaVotS  (■••d*r(eo.Of_T«p*»)p  1,  1)  } 
•nd  WmmAlinm  i 


(<af>  to  eoit)t 
r.eiM)  f 


•  o  i)» 


•ioalote  (*8»tojr  fix* 
tioaeot  LiM  (riXoji*a*p 
veil*  r.eiM  >  o  loop 
hoplo 

W.dat  Naokiao  (rlia_am(l. -r.llia) )  i 
tia.Pat  (‘<or>  to  eentlan.')  I 
tio.aat  Llaa  (Baf,  l.l)  > 

— ■  IN.DlBpiay  Tabla  > 

—  tio.Pat  ('<ar>  to  oootiaa.*)  | 

—  tio.aot.Llaa  (laf,  B_B)  t 
aio.elaar  i 

laadiiaa  i 

olo.Patac'Xaitiai  Tm  1  (<er>  to  quit)i 
10-l*lo_Of_Tapaa,  l)i 

tlo.aat.ilao  (Tm(>).xalt,  Tm(i>-ai«o>  i 
abila  Tm(i)-lioo  *  *  loew 

for  i  la  2..Tm-aaapa'iaat  loop 

nlo.lata(*Xnltial  Tm‘  *  iatopar'lwapa  (1)  4 
'  (rer>  to  pait)i  ■,a41*l-l«Bo_Of_Tapoa,  1)| 
tio.Pat  Uaa  (Tapa(i) .Xalt,  Tm(i)-*lo*>  > 

if  TmTi)-*ioo  ~  0 
Tm(i)-*i*0  >■  1  I 
TmtD-Iaiili)  >*  '''  > 

and  if  I 
and  loop  | 

oio.PwtK'atart  Itatoi  ',  10,  1)  i 
tio.aat  Uaa  (Btata,  l.liaa)  i 
a_a.Xapot  (Btata  (l..B_Biaa>)  | 

•  ft.oooo.elooo  ( 

Bio.fvte(*N*x.  eo.  of  %t»pm  (0<ex>  *  10000)1  *«  12, 
ilo.aat  (Man  BMpa)  >  tio.Bkip.Uaa  | 
if  Haa_Btm  o  0  than 
Maa.Btopa  10000  t 
aad  If  > 
aio.elaar  t 
baadllaa  | 
bapia 

Btata  io  Bt.Blwalata  (Tapa,  Btata, 

traa,  traa,  1.29,  Haa.Btapa)  ) 
Maaa»p.  ('Maehiaa  laltad  *)  ( 

Jornm a ototo  Icror 

WBBBBfB  (*ll*nSi—  Bolted  *)  ) 

Maaaapa  ('Btata  Traaaitioa  raMo  Irror*)  I 
abaa  TM.Tm-b**<r>^ 

Poooo/po 

(■aaa  off  ripht  and  of  tm  —  poaaibia  iaflaita  loop')  I 
whoa  Ol.Tm-ba^triow  •!> 

Maaaapa  ('Baa  off  loft  and  of  tm  )  ) 

«dMi  fM.rape.Brree  ^ 

Maaaapa  ('OBoapaetad  tm  faiiara'}  i 
k.Tlaa_laea.d.<l  ■» 


('BBoaodad  Man.  Btapo  —  Poaaibia  iaflaita  loop')  i 


•ad  f 

•io. Clear  t 
Bsadliee  ) 

olo.PatBCXnltiai  Tapa  1  (<er>  to  pait)! 

',  10-2nto  of_Tma>  i)> 

tio.Bot.Uaa  (Tapa(l).Xait,  Tapa(l).BiBt)  i 
aad  loop  t~ 
aBoaptioa 
abaa  otharo  ^ 
tlo.low  Uaa  t 

tio.Pat  (■••••••  •  4  piUJIm  (l..P_Biro) 

4  '  error  —  <er>  to  oontlnoa')  i 
tlo.Oat.Uao  (Piia.Im,  P_Bita)  i 
aad  I 

TM.Bad.Blw  I 
aio.Ciaar  | 

BesdXiee  i 

alo.Pota  ('Bator  file  aaa.  (<er>  to  qalt)>  ',  I,  l)i 
tlo.Bot_Uaa  (Piia.lm,  P.Blaa)  i 
•ad  loop  I 


taecin  —  fM 
•iOoCleat  ) 


8.2.2  The  package  tm_machine_sim 


with  TariB^T«lp»,  fN_St«t»_tK«i«itioft_Cofttcoi  } 

9»— rio 

■o_0<^T«pM  t  powitiw*  I  I 

•tax  StAtejlMM^tiM  t  poaitiwa  t«  12  i 

NMhiM^aOW  I  MtUCftI  !•  •  ) 

Mawhif  _cp1  t  MtuKAl  I*  It  t 

•T_aew  t  Mtorti  !•  21  1 

er.coi  I  Mtocfti  !■  40  t 

pwokae*  ToriAOLluehiM.eia  la 

paokaga  iM.T^pa  la  aaw  Tociae-*^* 

(  ao_of_Tapaa  ^  eo.of.Tapaa, 

Pep  Bow  Naohiaa.Bow  •  S*Be  of  Tapaa, 

Baad.colaaa  ->  llaehiiia.CoU2  )  2 

paokapa  tN^BT  ia  aaw  TM_ttata_Tsaaaltioa_CoatxoI 
<  Bo^M^eapaa  «>  Bo_of_T^aa  )  i 

aubtppa  ttata.Baaa.ttxinp  ia  tN_tT.Btata.Baaa_ttriap  / 

anbtypa  hotico_Baoord  ia  tN_tT.Aotioa_Baoocd  i 
aabtypa  Tapa.Baapa  ia  TN.tT.Tapa.Baapa  i 
aabtppa  tyBbol^hrgay  ia  tw_tT .  tyabo  l^hggay  i 

typa  Tapa_XBit_Bae  ia 
raooad 

Biaa  I  aataral  0| 

Zait  «  atxlap  (1  ..  255)  t 
and  caoord  t 

typa  tapa_Zait_hcray  ia  array  (Tapa.Baapa)  of  Tapa_Zait_Bao 


Tapa.Baapa  Brxor  i  aaoaptioa  2 
TiM.Baoaadad  t  aaoaptioa  f 

ttata_Brrec  t  aaaaptian  raaaaoa  fll_tT.ttata_Brror  f 
Oata.Brror  t  aooaptioa  raaaaaa  tM_eT.Data_Brror  $ 

tapa.Oaarflow  i  aieoaptioa  raaaaaa  tM.Tapa.Tapa.Oaarfiow  f 
Tapa^Oadarfiowt  asoaption  ranaaoa  tM.Vapa.Tapa'oadarfiow  i 
Ti^.Brror  i  aatoaptioa  raaaaaa  TM.Tapa.rapallrror  j 

prooadnra  eat  Naohiaa  (Pila  Baaa  i  atriap) 
raaaaaa  TN.er.eat.Haohiaa  f 

pcooadora  Diaplay  Tabla 

raaaaaa  TM.BT.Oiaplay.tabXa  t 

faaetioa  Biaolata 

(Zapot  t  Tapa_Zait_Array  2 

ttart  I  •tata.Baaa^ttriap  2 

0B_eoraaa  t  boolaaa  i*  faiaa  | 

•iaeia_5tap  t  booiaaa  t«>  faiaa  2 
Paaaa  i  Ooratioa  l.SO  2 

Nax.ttapa  i  aatacai  i*  1000  )  xatam  ttata.Baaa^BtriBp  ) 


—  fvaCoad  i  eat.Maehiaa  haa  baaa  oaliad  to  iaitialiaa  a 
Boohiaa  ~ 

--  Poatcetidt  Batoraa  tha  taxaiaitiag  atata  of  tha  oacktaa 
SiBoaptieaas 

Tapa^Oadarflew 
—  Tapa.ovarflew 
Tiao.Baeaadad 


foBOtioa  Tapa.eiia  (Tapa  s  Tapa.Baapa)  ratara  aataral 
raaaaaa  fN^Papa.Tapa.Bisa  ; 

faaetioa  T^a_Piaea  <Tiva  t  Tapa^Baapa  i 
Laft  t  aataral  i*  1  j 
Biphtt  aataral  )  ratara  atriap 
raaaaaa  TN_Tapa.Tapa_Piaea  i 

faaetice  ■aad.Poaltion  (Tapa  t  Tapa.Baapa)  ratara  aataral 
raaaaaa  Tli_Tapa.Baad_fooitioB  t 

faaetioa  Traaaitioa  (Btata  i  Btata_Baaa_BtriBp2 

•ybol  t  5yabol_hrray)  ratara  hotioa.Baeord 
raaaaaa  TM^er.TranaitiM  / 

faaotion  Valid_Btata_Baaa  (ttata  i  Btata_Baaa_ttriBp)  ratara 
raaaaoa  TM.BT.Valid.ttataJlaoa  t 

preoadara  Bad^tia 

raaaaaa  fN^BT.Bad.tia  f 

aad  Tariap^Naohiaa.Bia  2 


- - - ... - -  BOOT  - - - 

with  ttriaf^Boaaaar  ; 
with  fa«t_zo»  Besaaa_ZO  2 

paokipa  badty  Tariapjiaehiaa.Oia  ia 

pankipi  ia  aaw  OtriMLBeaaaar 

(MaB_eabatriaf.Biaa  ■>  Max.Btata ji«aa_tiaa )  2 

pankapa  tie  raaaaaa  tast.ZO  2 
pankapa  ala  raaaoaa  Beraaa^ZO  2 

Zaitialiaad  1  boolaaa  t«  faiaa  2 

•iaolatiap  1  baelaaa  faiaa  2 

Oa  Boraaa  t  beolaaa  i«  faiaa  2 

Baltad  t  boolaaa  t«  faiaa  2 

prooadara  Ba«  (Bew  t  aatwral)  ia 

bapia  —  Boat 

aio.BotB  Bew«  Baohlaa  Col)  2 

for  i  ia  l..Mas_ttata.Baaa  tlsa  lo^ 
aia.BwtC  {*•*,  Bow,  WanS<Ba_Col»l»i)  2 
aad  loop  2 

alo.Bott  (*-♦*»  Bow,  liaohiaa_CoU244iaa_Btata_BaM_tiaa)  1 
aad  Booi  2 


preoadara  Diaplay_ttata  (ttata  1  ttatajiaoa.ttriap  2 
Btap.Bot  aataral  )  ia  ' 

bapia  —  Biaplay  ttata 

»  aio.»vtB(*Beai  *,  l,  l) 

I 

Boo  (waoklaa  Bow)  2 

—  aio.fvtai'loK  i  1,  D) 

•io.tot*  (’I  *  t  atat*  a  *  |’,  NaaklM_Ba<>.l,  WanS<aa_Col)  i 

—  alo.f«ta(*aeK  i  ■,  1,  1)1 

Boa  (llaakiaa,aa«.2>  t 

~  alo.fvtB(*<iaa  *,  1,  1)| 

aia.xotn  (*atap  Bo.  *,  Btap.Bo,  MaeUna  Bon-l,  1)  i 
aad  Diaplay_ttata  2  ' 

prooadara  biaplayjhetioa  (hetioa  t  Betion_Baoord)  ia 

bapia  —  Biaplay^hetioa 

••  aio.Bett  (Mtata  Traaaitioa”  ,  BT  Bow, 

tr  col)  2 

oio.fete  (*Ba]rt  ttatai  *  4  Botiea.Baxt  ttata,  BT  Bewfl, 
•t.CoI)  2 

for  i  ia  Tapa  Baapa  loop 

oioaPotB  (*Tapa*  4  iatapar'iaapa  (i)  4  *t  ” 

4  Betioa.h0tioa(i)aBow_ByB  4  * 

4  hotioa.hotioa  (i)  .Baad.Nawa, 

BT_B0Wft4i  ,  BT.Col  )  2 
aad  loop  2 

aad  Diaplay^Botioa  2 
preoadara  Braaa.Betioa  ia 
bapia  —  Braaa  hetioa 

aio.potB  (*  *»  BT  Bow,  BT_Col)2 

aio.Pott  (*  ”,  BT_Bowfl,BT_Cel)2 

for  i  ia  Tapa  Baapa  loop 

aio.Pott  *,BT_Bew4l4^i,tT_Cel); 

aad  loop  2 
aad  Braaajhotioo  2 

fvMtioa  Biaolata 

(Zapot  I  T^a_Zait_hrray  2 

Btart  t  Btata^Baaa^Btriap  2 

Oa^Boraaa  1  boolaaa  !■  faiaa  2 
Biapla.Btap  1  beoloaa  faiaa  2 
Paoaa  1  Doratioa  t*  1.50  2 

Naa^Btapo  1  aataral  i*  1000  )  ratara  Btata_Baoo_Btriap  ia 

Corraat.Btata  t  Btata JB«M_Btria«  Btart  2 
Coatiaoooa  t  boolaaa  ••"’aot  Biapla^Btap  2 
Daar^Btop  1  aataral  1*  0  2  ' 

Naa.eaar.Btopai  aataral  i*  1  2 
Btop^vo  I  aataral  i*  0  2 

Corrmt.Byoboli  Byobol.hrray  2 
hotioa  I  hetioa_Baoord  2 

Boffar  t  atriap  (l..t0)  2 

B_Biia  2  aataral  2 

prooadara  Oat^Tapa^tyabola  ia 

bapia  <->-  eat_Tape_Byofaola 
for  i  ia  Tapajaape  loop 
TN  Tapa.Baad.Baad  (i,  Corraat.ByoboKi) )  2 
aad  loop  2 

aad  eat.Tapa.Byobola  2 
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(CooaAK*  Opdata.Tap*  (taf*  ■  Tap*_>aM*>  ^ 
hsfiB  —  llpd«to_*av* 

X(  «atiaa.«atla«(Tapa).a««_fjB  •  tlwa 
IN.tapa.iariM.aMd  (*•••,  Caxraat_()akal  (Tap*))  | 

alaa 

IN  Tapa.llxtta_laad  (tapa,  Patlaa.*atiaa(*apa).Paar_*]B|  > 

aadPiX  I 

Caaa  Patiaa.atBtlaB(«apa).aaad_Meaa  ia 
ahaa  '>'  •>  ac*apa.lto«a_aaad_PlAt(Tapa)  i 
atwB  '<*  o  a^«aM.ltoaa_aaad_ta(t(Vapa)  i 
afcaa  otkaca  v  a<^  > 

aad  aasa  i 

aad  Opdata_Tapa  i 

taaolB  —  PUailata 

■altad  (alaa  > 

£odt  ^  £jk  Ttts#  Bums  looo 

W.TBV* a XaltiaiiM ( i «  Zapit(i).xalt  (l.«lApvt(i).tiM)  )t 
•ad  loop  I 
IJ  Oa.Bec««a  tli*a 
*•  •ia.Claac  i 

—  •io.Pvtt  (*PiapI«y  ea*p  Ipl)  t 
Wjlmf  a  DisplayjOa  i 

—  aiOaPotS  (*Tap«  iflwiia*#  I,  1)  t 
Display.Stat*  <ew»«at_ttat«p  tt«p_ao)  j 

•ad  if  I 
aias_toop  I 

••  af  -Patt  ('Bapia  Loop  *»  L«  t)  f 

dot_Tap«  Byatolo  } 

—  aiOaPutB  (‘Traaaitioa  */  1#  1)  ? 

JUttioa  !•  Vraaaitioa  (Caxsoat_Btata«  Caggoat^tyahol)  } 

—  Diaplay.Tabia  ) 
if  Qa  Socaaa  BBaa 

«  ■lo.BtttS  <*Dioplay  Botioa*,  1*  1)  t 
Display  Botioa  (BotiM)  i 
if  Coatlaaooa  th»n 

dolay  Baoao  i 
•lao 

Oooz.Btop  Oooc_stop  *  1  I 
Zf  Oooc.Btop  >•  Naa.aoar.fttap*  tlMa 
Oaos.Btop  t«  0  I 

•iOaVtttB(*C(oat)  0<ait)  #P#  t  %  2t,  1)  t 
tioadat  Liaa  (Doffosp  B.Biao)  i 
if  B.Biaa  >  0  tkaa 

Caaa  Boffac  <i)  ia 

ahaa  'o'  I  'C'  ^  Coatiaaooa  tsaa  j 

aPaa  'p'  |  'Q'  aait  Bio  Loop  | 
aBoB  '0'  a.  'f'  «> 

Naa  Oaoa  BLapa  i* 

'"aatwal'aalaa  (Baffa«(laaB.Biaa))  i 
ahaa  otkoca 
aoXX  ; 
aad  oaaa  | 

•ad  if  I 
aad  if  I 
•ad  if  I 

—  aio.PotB  (*Bcaaa  aotioa**  1#  1)  i 
Braao.LoCioa  | 

aad  if  I 

for  i  ia  Taps  Baapo  loop 
*«-  aio.PatB  (^Opdato  tapo*i  Ip  1)  f 
Opdato.Tapa  (i)  i 
aad  I 

Casraat^B^ato  i«  Aotioa.Baat.Btato  $ 

Btop.Bo'' !•  Btop.Bo  t  t  I 
if  Ob  Beraan  tlMa 

—  alo.PatB  < 'Display  atop  #  aad  aarraat  atato'p  Ip  1)  t 
Display  Btata  (Corcaat.Btatap  Btap_Bo)  | 

•ad  if  I 

if  Btop^Bo  >  Nax.Btopa  thaa 
raiaa  Tiaa.Baoaadad  i 
•ad  if  I 

•ad  loop  Bia_Loop  i 
ratara  Cacraat^BLato  j 

•aOMtiOB 

i^aa  Btato.Bsror  ^ 

■altad  !■  traa  i 
ratasa  Carraat^Btato  i 
•ad  Biaalata  i 


•ad  Tariagjlaehiao.Bia  ; 


8.2.3  tm  State_Transition_Control  Package 


witk  •tciiia_ee«MMiS  > 
auMKie 

ao.Of.T^M  t  positive  I  ..  i«  I  I 

Nu.etate.aaM.SiM  t  poeitivs  i-  12  i 

paolM9»  VM_St«t«.TSttiMitiMi_CMtsol  im 

pMlUp*  •  e  i«  MM  etciaaLSCMMUMIX 

<itex.eabstciae^eiM  NM_etat«ji«M_siM)  i 

•ttbfpp*  TofcM  asoord  i»  e.e.TiDiMa  vpp*  i 
•vbtppe  tt*telB«M_etriAa  is  striM  <l..ltaa_etsts_««M_eiM)  t 
•obtpps  TSpS.aMp*  is  pOSltiM  SMfB  1  •  .BO  Of _VSpSS  f 

typs  Byakol.Jkrrsy  is  srssy  (Vsps.fUspa)  ci  skassotss  i 

typs  Tsps^astios  is 
ssoecdT 

BsM  Bya  t  olMcsetss  i*  '  *  | 

BssS^Boss  I  ohsssotsr  !•  *  *i 
ssdi  xsoocd  I 

typs  aotios.arssy  is  array  (Taps.Ba&as)  of  Tapa.ketios  | 
typs  aotios_asoord  is 

BsjBt.etats*  Btats^BaM.Btriaf  t»  (Othsrs  ■>**)} 

Astios  I  Aotioa.Array  t 
snd  rsoord  | 

■tats^Brror  i  saosptioa  | 

Data.Brror  i  ssosptios  | 

proosdors  Bst^MsokiM  (Pils^Baas  t  atrisa)  | 


••  Prseood  >  PiisjBaM  is  ths  aaas  of  a  fils  that  oostaims  a 

—  oorroot  daseriptios  of  Tarisp  WaohlM 

—  Postootidt  TiM  psckaas  is  isitialissd  Mxtk  tlM  fM*s  stats 

~  trassitioB  tablo 

—  IjBooptiooi  Oata.Brror  iff  fils  fonat  srror 


pcoosdoro  Oisplay^Tabls  f 


<—  Prsoend  t  est^NaohiM  mss  oallod  asd  tsrslaatsd 
—  sMOSssfolly 

— >  fostoondi  eisplays  tks  stats  trassitioo  talils 


proesdors  Display_Oe  ; 
proosdors  Display.Off  | 

fvBOtion  transitloo  (Stats  t  Stats_Baas_StriBai 

iybol  t  Sysbol.Array)  rotten  Aotios^Bsoord  } 


—  Prsoood  t  est_llschiM  mss  oalisd  and  tsrsinatsd 

—  sooosssfnlly 

—  Pestoondf  rstoras  thm  traMitios  for  tte  (Stats*  Sysbol) 

pair 

Baosptisni  Stats_Brror  if  m  stats  transition  dsseribsd 


typs  StM.Bsoord  is 

Stats  I  Stats  BSM  Strisa  I 

T.Ust  I  T_L.LXst_<^ps  I 
snd  rssoed  i 


^  Spsotfisations  of  snpport 
—  List.Mt  I«t  Mitk  Stats  BS 


to  iastantiats 


,n. 


(Sosros  t  in  Stats.Bsoocd  i 
tnrant  t  in  set  Stats.Bsoerd)  t 


prnnadnra  NsssJbid.Bssst 

(Seer OS  t  in  eat  Stats^Bseord  » 
Vnrast  I  in  sot  Stats.Bsoosd)  t 


fonetien  *■*  (fcsft*  Biakt  i  Stats.Bsoord)  rstnm  boolsan  j 
psekaas  S  X.  is  nsM  List 

(Stats.Bsoesd*  Copy,  ness.And.Bssst*  Sap*  *•*)  t 

Xnitialissd  t  Boolsan  i*  falsa  t 
Cn^Sorssn  t  boolsan  falsa  i 
Corrsnt.Stats  s  Stats.Baaa.Strina  t 

Stats.List  I  S_L.List.Typs  i 


••  Bodiss  of  ai^pfirt  preesdnrss  rsqairsd  to  iastantiats 
List_^pt_tpt  Mitb  Stats_Baoocda 


pcoosdnrs  Copy 

(Seoros  t  in  Stats.Baeord  i 
Tarpat  i  in  oat  Stats.Baeecd)  is 

bspin  Copy 

Tarpst.stats  t*  Soares. Stats  ) 

T_L.eoff  (Beatea.TJdmt,  ru«.t.T_U.t>  i 
md  eepf  I 

ttoaa^m  HM._JUid_a.Mt 

(•MCM  I  ia  oat  ttotojueeod  j 
Tur«M  I  la  tmt  ttotojaoood)  io 

hmgiM  —  HM._JUid_a.Mt 

•uVat.aMt.  !■  •o.EM.at.t.  ; 

*  If.HM.  aad  aH.t  (aowM.T_U.t,  tugM.*_U.t)  I 
Md  00*0  aad  aM.t  > 


proMduc.  I.p  (aeuTM  i  ia  o<it  *tat._a.Mrd)  la 
ba«ia  ~  lap 

T_L.l.p  (■owM.X_Liat)  I 
Md  lap  I 

fmetlM  *•*  (laft,  alqht  i  Stata_aMMd)  ratMB  boolaM  i. 


foBotiM  v.lld_at.t._HM.  (atat.  I  at.t._HM._stiia9) 

xatwa  boolMa  i 


—  PEMMd  I  d.t_HMMM  M.  oallod  Md  taralnatM 
..  soeosddfally 

Postooodi  rstoTM  tros  iff  Stats  is  a  valid  stats 


pcoosdors  Bnd.Sia  | 


MM  Prsoond  s  non 

—  Sosteeodi  rstorns  tbs  psokaps  to  its  initial  oondition 


sad  tM_Stats_Transitien_Contrel  t 

- - - —MM - -  BOOT  - - - 

Mitb  List_Bt_Lpt*  List_Lpt_Lpt  f 
Mitb  Tsvtlzo*  Sorssn.ZO  t 

psokaps  body  tN_Btats_Traasition_Coatsol  is 

psokaps  tie  rsaaass  isxt.ZO  | 
paoka^  sio  rsnaBss  Scrssn.ZO  f 

typs  Transition.Bsoerd  is 
rsoord 

Syobol  I  Syobel.brray  $ 

Bent  Stator  Stats_Baas_Strinp  t 
Aotion  t  botion_brray  i 

snd  rsoord  i 

psokaps  T_L  is  asM  X>ist_Pt_Lpt  (Transition.Bseord)  t 


bspin  *-* 

rstom  false  i  Bet  osed 
sod  *■*  I 

proesdors  Sst.llaebiM  (rils_BMS  <  strinp)  is 

2n  rile  r  tie.fils_Typs; 

Bi^fer  t  strinp  (1..29S)  f 
B.Siss  I  Mtoral  I 
Stets.Bse  I  stats  Bsoord  i 
Trans_Bso  i  sraMitioo_Bseerd  } 

Toksn.Btf  I  Teken.Bseord  f 

preosdars  Sst_Transitisn_Bsoord  is 

bspin  —  eet_traMition_Bsoord 
fsa  1  Mass  Banos  looo 

Trans_Bso.SynCol(l)  i*  Toksn.Bof  .Pises(l)  } 
tiOaPot  (*  *  S  TraM_Bse.Synbol(i) 

if  i  /*  Taps^Banps'Last  tbsn 
pBfcsn_Baf  I*  S_S.Soan  t 
end  if  t 
end  loop  I 

Ttsm  Bso.Best  Stats  t*  S  S.Soan. Pisco  9 
tie. Pot  (*  *  L  traM_Bso.Boat_stats)  } 

for  i  in  T^s.Banps  loop 
Token  Bof  !•  SB. scan  1 
if  token  Bof. Sins  ■  1  tbsn 

Trans  Bse.botien(i).BsM_Syo  Toksn.Mf  .Pises(l)  f 
tie.Pat  (*  *  S  Trans_Bse.Aotien(i).BSM_ByB  4  *  ")  r 

else 

tie.Pat  (Toksn.Bof* Pises)}  tio.BsM.LiJis  } 
raise  Data.Brror  } 
snd  if  I 

Toksn.Bof  I*  S_S.Soaa  } 
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if  vokM  enf.slM  •  1  tlMw 

c—  Tiolwn_laf.tiM«(l)  im 
•<*  I  *>*  I  ♦-*  •> 

I- 

Tdkmm  ■Bf.VittMfll  t 

tie.Wt  (Tr«M_RM.Aati«i(i).aMd_llm  ft  '  *)  > 

oUmts  ^  r4iM  tet«_lcsoc  } 

•ad  ••••  I 

•!•• 

tio.9«t  («olMa_aaf  .viae*)}  tie.Mw_Liatt  i 
rais*  Data_lKKOff  i 
•ad  if  I 

if  t  I.X»  Bvty  (St«t«  a»c.T_X.i»t)  tlM 
t  l.Xaaaat  firat  (Yraaa  ftae,  Stata  tee.f.Liat)  i 

•laa 

t  l.Aipfaad  (dtata  dao.Y  X*iat«  Traaa  Mae)  i 
•ad  if  I  ~  ~ 

tio.daa.Liaa  i 
•ad  Qat,taaaaitioa_>aoocd  i 


•ad  ioop  I 

taat  M.  tot  (*  *  ft  Aatiaa^Xafa.daat.dtata  )  ; 

fac  I  ia  Ya^a  ■••••  ioop 

«a«t  XO.  Vat  (*  *  ft  tetioa_Xafo.Aotiea(i).daw_«ya 

ft  *  ft  ABtioa_Xafo.A0tiaa(i).daad_Naaa  )  ; 

•ad  ioov  I 
Vast  XO.daa.Liaa  i 
Coatlaaa  t*  traa  i 
•ad  Ttftaaitiaa_A0tioa  i 

yaeoadaca  dtata_Aotiea  (dtata.Xafo  t  ia  dtata  ftaaocd  t 
■at.Oaad  i  ia  oat  Bet  Baad_— ooad  i 
Caatiaaa  t  oat  boolaaa  )  ia 

hagia  —  Stato^ftotioa 

faxt_XO.V«t  (Stata_Xafo.Stata)2  tost  io.Moa_Liaa  t 
ftaaaraa.VKaaaitiaaa  (ttata.Xafo.T^XiIat,  Vot.Oaad)  i 
Vaat  Ic.Baa^Liaa  f 
Coatlaaft  i*  traa  i 
•ad  •tata.Jkotioa  i 


ba^ia  —  dat  WanMaa 
•  i.lav  (ttata^Xtiat)  i 

tXe.Opaa  (Xa.rila,  tio.Xa^filat  rila.Baaa)  i 
tio.Vot  (*YN  Stata  Traaaitioa  Tabia*)i  tio.aaa.liaa  t 
akiia  aet  tio.lad_Of_Viia  (Xa  Vila)  ioop 
tio.dat.xJjM  (Xa_Vila«  Baffar,  ■  tiaa)  i 
•.t.Xapat  (Baffar  (l..B_Siaa)  )t 
•tata.Bao.Btata  t«  s_B.taaa.Biaoa  } 
if  stata  Bae. Stata  (X..2)  -  *— *  tboa 
tie. Bat  (Boffar  (l..B_Siaa))  i 
tie.Baa_Liaa  | 

•laa 

tie. Bat  (Stata_aao. Stata)  i  tio.Baa.Liaa  } 
tio.dat.Liaa  (Za_rilat  B^far,  B.Siia)  } 
S.S.Xapat  (Boffar  (t..B_Siaa)  )} 

Tekaa^Bof  s«  S^S.Soaa  t 

«dd.la  (Tokaa.Bof  .siia  /■  0  )  loop 

—  aad  (Vokan  Bof.Biaea(l)  /*  '**)  loop 
if  (Tokaa.BofTsita  >•  2) 
aad  tlMa  (Tokaa  Bof •Biaoa(l. .2)  •  *— *)  tlMn 
tie.Bot  (Baffar~<l..B_Siia))  | 
tie.Baa_I.iaa  ) 

•laa 

Oat  Braaaitiea.Baeerd  | 
aad  If  I 

tie.0at_Liaa  (Xa  Vila,  Boffar«  B  Sisa)  i 
S.S.Xapot  (Boffar  (X..B_Siaa)  ); 

Bekaa_Baf  i*  S_S.Seaa  | 
aad  1  wre  t 

—  if  (Vokaa.Bof .siaa  ■  1) 

••  aad  (tekaa^Bof  .Biaea(l)  •  '-*)  tbaa 

—  if  aet  S_S.Bad_Of_Strias  tlMa 

—  dat_Traaaitiea_Baeerd  $ 

•ad  if  ) 

—  alaa 

••  tie.Bot  (Tekaa.Bof  «Biaoa)i  tie.Boa^Liaa  ) 

—  raiaa  Data_Brrer  i 

—  aad  if  I 

if  S.L.Xa.Bapty  (Stata.Liat)  ttea 

S_L.Xnaart  rirat  (Stata.Baef  stata.Xdat)  f 

•laa  ' 

S_L«J^paad  (Stata_l.iat«  stata.Kae)  i 
•ad  if  j 
tio.Baa_Liaa  f 
and  if  ) 

•ad  leap  ; 

tie.Cloaa  (Za_Fila)  | 

Xaitialiaad  i«  troa  i 
•ad  dat_luoliiaa  | 


baaia  —  Biaplay  Tabla 
if  Xaitialiaad  tEm 

Traaaraa_Stataa 

•ad  if  f 
•ad  Diaplay_Tabla  i 

pceeadora  Biaplay_Ca  ia 


(Stato.Liat,  Bet_Uaad)  ) 


bapia  Diaplay_Oa 
Oa.Seraaa  i*  troa  i 
•ad  Diaplay.Oa  t 


pceeadora  Biaplay_Off  ia 

bapia  Diaplay.Off 
Oa_Seraaa  i*  falaa  } 

•ad  Diaplay_Off  i 

foaotioa  traaaitiaa  (Stata  x  Stata_Baea_striap  i 

Syabel  t  SpariMl.brcay)  ratora  aetiea^Baeerd  ia 


typa  Batora.Baeerd  ia 
raeerd 

Begad  t  beelaaa  i*  falaa  ) 
Aaagart  actiaa_Baeecd  t 
aad  raeocd  | 


e.Stata  I  Statajiaaa_Striap  i*  State  ) 

Aaaaar  i  Batora_Baeerd  ) 

pceeadoKa  riad_Stata  (S_Bae  t  ia  stata^Baeerd  t 
C_Stata  I  XM  eat  Stata^Baaie.Strlap  ) 
Coatianai  eat  beelaaa  )  i 

pceeadora  Vraaaraa  Stataa  ia  aaw  S.L.Bae_Sal_Xtarater 
(Stata_B«w_StrXap,  Biad.ttata)  ) 

pceeadora  Biad.Traaaitiea  (Aet  x  ia 

Traaaitiea.Boeerd  T 

Aaawar  x  ia  eot  aetara^Booocd  } 
Ceatiaoa  i  eot  beelaaa  )  ) 

pceeadora  Traaaraa_Aetieaa  ia  aea  T_L.Bac_sal_Ztarater 
( Batora_Baoecd»  iad_Tr aaaitiea )  i 

foaotioa  Natob^Op  (Spslr  Sya2  i  syofael^Array) 

ratora  beelaaa  ia 


Aaaoar  i  beelaaa  x*  troa  i 


pceeadora  Oiaplay.Tabla  ia 

typa  Bet  Oaad.Baeerd  ia 
raeerd 

Bet_oaod  I  char acta*  ' 
•adT^raoerd  i 

Bet.Oaad  t  Bet_Oaad_Baeecd  i 


bapia  ••  Nateh_Op 
fee  i  ia  Tape  Banpa  leap 
if  Syol(i)  /•  aad  tbaa 
Sri2(i)  /•  aad  tbaa 
SyBl(i)  /•  S^(i)  tbmi 
Aaaoar  t*  falaa  } 

•ait  I 
•ad  if  ) 


pceeadora  Stata.Aetiee  (Stata.Xafe  i  ia  stata_Baeerd  | 
Bot_(laad  t  ia  eot  Bet  Oaad_Baeord  ) 
Ceatiaoa  t  eot  beelaaa  J  i 

pceeadora  Traoaraa_stataa  ia  aoo  S_L.Bae_sal_Xtarater 
(Bet_Caad_Baoerd»  Stata_Aet iea )  ) 


ratora  Aaawar  | 

•ad  Nateb.Pp  ) 

pceeadora  Biad.Stata  (S_Bae  i  ia  State  Baeerd  x 
C_Stata  I  la  eot  Stata_Baaa  Strlag  ) 
Ceatiaoa I  eot  beelaaa  )  la 


pceeadora  Traaaitien  Aet iea 

(AetXea.Xafo  x  ia  ttaaaitieo.Baeerd  i 

Bet.Oaad  i  ia  eot  Bet  0aad_Baoord  i 

Ceatiaoa  i  eot  beelaaa  )  i 

pceeadora  Travaraa_yraaaitioaa  ia  aae  T_X..Bae_Sal_Ztarater 

(Bet_Oaad_Baoord»  tr aaaitiea^Aetiea )  j 

pceeadora  Tcaaaitiea  Aetiea 

(AetIea_Xafo  t  ia  tcaaaitiea_Ba ear d  i 

Bet_ltoad  •  ia  eot  Bet  Oaad.Baoerd  » 

Ceatiaoa  t  eot  beelaaa  )  ia 

bapia  —  Traaaitiea.Aetiea 
fee  i  ia  Tape  Baaea  leap 

TOxt.XO.Bot  (^  'ft  Aetioa_XAfe.Syobol(i)  )  t 


bapia  —  Biad_Stata 
if  S.Bae. Stata  -  C.Stata  than 
TraWraa_Aetieaa  (S_Bac.T_Liat.  Anaear)  ; 
Ceatiaoa  i«  falaa  t 

•laa 

Ceatiaoo  i*  troa  ) 

•ad  if  I 

•ad  riad_Stata  i 

pceeadora  Biad^Traaoitioa  (Aet  x  ia 

Vraaaitiea_Baeecd  T 

Aaaoar  t  ia  eot  Batorn_Baeerd  t 
Ceatiaoa  x  eot  beelaaa  )  ia 


tbaa 


bapia  —  Biad.Tranaitiea 
if  Nateb.Op  (Syobel,  Aet.Syobel) 
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Mmmms  t«  (tew*  Aot.tetioa)  )  > 

Owitiil^  !•  f«XM  I 
•Im 

Comtimom  <•  tnm  i 
•Ml  if  I 

Mid  riad^tsftMitiflii  } 
to^iii  TTMMiiiott 

TcAVMSs  ttat**  (ttftta  ULsi,  c  ttmta)  } 

if  AMMwr.roMid  tlM» 

•lam 

r«iM  I 

•ad  if  I 

•ad  Traaaitioa  i 

foaetioa  Valid.dtata.Vw  (Stata  i  Stata.HMM.steiaf)  satnra 
taoola«a  is  *’ 

foaotioa  «<•••«••  <Liat  t  d^L.Liat^Typa)  ratara  boelaaa  is 
ba^ia  — >  Tsaaaasa 

if  State  •  S^L.Casraat.Objaot  (List). State  teaa 
sstara  traa  > 

•Uif  S.L.Xa.tepty  (S_L.TaiI.of(Liat))  teaa 
aatasa  falsa  | 

•!•• 

ratora  traaarsa  (S_L.Tail_Of  (X»ist))  ) 

•ad  if  I 

•ad  Tsaaassa  i 

bafia  *>*  Valid_State_laM 
if  S.L.Zs.tevty  (Stete.List)  thaa 
xatura  falsa  | 

•Isa 

ratora  Traaaxss  <Stete_List)  j 
•ad  if  I 

•ad  Valid.Stete.Saas  } 


bsoia  —  ■ad_Sla 
Xaltialissd  t«  falsa  i 
S.Xi.l^  (Stete.Xtist)  I 
•ad  ■ad.Sia  i 


•ad  fM_Stete.9raasitioa_eeatcol  t 


8.2.4  The  Turing_Tape  Package 


Tkia  paok«e»  Miataia*  aad  (oytiaaally)  display*  Tariap 
•o  aasliias  taps*. 


fsasrio 

ao.Of.Tapss  t  positiss  }  —  1..3 

Top  aoAf  I  aatarat  3  i  eoasaa  posi^iaa  of  taps 

■sad^Colosa  i  aatscal  i*  30  }  — >  pesitioa  of  a/W  haad 

lua_Taps_eiso  t  in  to  par  !«  1300  i—  Naa  siss  of  taps 

paekaps  Toria^LTaps  is 

SQfatyps  Taps.aaaps  is  positios  saaps  1 .  .ao_0f_Yapss  t 

Taps.Oosxfloo  t  ojpooptioa  ; 

Taps^Oadscf loot  saesptioa  } 

Taps.lxsor  t  oaooptioa  j 

pcoeoduro  taitiaiiao  (Tapa.Ro  i  Taps^Paapa}  itart  t  atriap)  t 


—  PraCoad  f  Pens 

PostCend  t  eioa  a  Taxiap  taps  aa  iaitial  oalos 


pcoeodaro  Display_Oa  | 


»  Procoad  t  eons 

PostCoad  t  Display  tha  carrant  t^pa  oa  tka  seroaa 


paooodoxo  Display.Off  i 


—  PxsCoad  t  Voaa 

PastCoad  >  Otop  diaplayiap  tJM  tapa 


pcooadara  Dsad  Baad  <Tapa_eo  i  ¥apa_Raap*i 

■yabol  t  la  oot  eharootac)  i 


PxoCoad  :  Tapa  oas  iaitialisad 

—  PostCoad  I  aotSTB's  tha  syabel  eurcsatly  baiap  scaaaad  by 

—  tba  m/«  baad 


fsaotioa  Csxroat.Oyabol  (Taps.Bo  i  Tapa_Eaapa) 

ratora  ebaraetax  i 


ProCond  1 
SostCond  1 

1  Taos  nost  ba  Xaitialiaod 

1  Pstoras  Synbol  oartar  tba  P/w  baad  9 

foaetian  Saad^Poaition  (Tapa^Me  t  Tapa_Ssnga )  ratora  aatoral  1 

—  PraCond  1 

—  PeatCead  1 

t  Mona 

1  Pstoras  Maad  position  iadar  9 

aad  Totiag^.Tapa 

9 

with  Serooa.XO, 

Tsat.XO  9 

paeksga  body  Toriag_Taps  is 

paokaga  sio  roM 

MSS  seraoa_xo  ; 

•aparator  t  ooaataat  obaraetor  t*  *  } 

Coraar  t  ooaataat  obaraetor  :■  ; 

Top  t  ooaataat  obaraetor  t 

P.W.Baad  I  ooaataat  obaraetor  i 

•laak  t  ooaataat  obaraetor  ; 

baft^Mpa  I  ooaataat  aatsral  t*  ■aad^Coloaa  /  2  ; 
Pipht.Mpat  ooaataat  aatoral  t«  (00  •  ■aad^Oolon)  /  2  i 

typa  Tapa^Doe  la 

Tapa  t  atriap  (l..Nax_Tapa_ftiM)  f 

baad  I  aatoral  1  i 

bi^t_tad  t  aatoral  >*  0) 
aad  raoord  | 

typa  Tapa.brray  ia  array  (Tapa.Raapa)  of  Tapa_bae  i 

Xaitialiaod  t  boolaaa  t*  falaa  } 
elBolatiap  I  boolaaa  t*  falsa  f 
Oo^ierooa  t  boolaaa  s*  falaa  i 


proeadora  Mrita.Psad  (Taps.bo  t  Tapa.Paapai 

•yitel  :  la  oot  obaraetor)  f 


—  PraCond  s  Tapa  oaa  iaitialisad 

PostCoad  I  bsplaes  tbs  tap*  poaitieo  eorraatly  baiap 
— '  aeaanod  by  tbo  P/v  bead  vitb  iyitel 


proeadora  Noos.eaad.Loft  (Tapa^eo  t  Tapa.baaps)  j 


—  Procoad  t  Tapa  was  iaitialisad 

—  PostCoad  X  Ness  tbo  P/W  bead  ooo  position  loft  on  tba  taps 

—  Saeoptiont  Tapa  Uadarfloo  if  tha  P/W  head  aDOos  off  tba 

taps' 


proeadora  iioao_Psad_Pipht  (TapsjPe  i  Tapa^Paaps)  ; 


—  PraCond  x  Taps  was  iaitialisad 

—  PootCond  :  Noos  tha  P/V  baad  ens  position  ripbt  on  tbo 

tapa 

—  Bacoaptioni  Tapa  Ooarfloo  if  tba  P/W/  baad  nooss  off  tba 

tapa 


preeodora  lad_3iaolatien  | 


—  PraCond  t  Mono 

—  PostCoad  s  Narka  tba  oorraat  tapa  aa  oaitialisod 


foaotien  Tapa_3isa  (Tapa^Me  :  Taps.Paaps)  ratora  aatoral  j 


••  PraCond  s  Mono 

Poatcofid  I  ratoraa  tba  laagtb  of  tba  aen-blaak  portion  of 
••  tbs  taps 


foaotien  Tapa.Piaeo  (Tapa_Mo  t  Tapa.Paap*  f 
Lsft  t  aatoral  1  f 
Pipht:  aatoral  )  ratora  striap  i 


••  PraCond  s  Mono 

PoatCond  t  Pstoras  Tapa  (Lsft.  .Piebt)  | 


Data  t  Taps.brray  i 

preoadora  Diaplay.Taps.Pyribola  ia 

baft  t  aatoral  t 
Ser^col  I  aatoral  t 

bapia  —  Diaplay.Tapa^eysbola 
for  i  ia  Taps.laaps  loop 

if  Data(i).Maad  >  baft  Me*  tbaa 
baft  to  Data(i).Maad-b*ft_ld9aft  r 

•er.col  I*  Hoad  ColssMt  -  2*(baft_ldpa>l)  t 
alas 

baft  to  1  > 

■or  Col  t*  ■aad.Colasi  •  2*(l>ata(i).Maad>l)  j 
sad  If  r 

itbila  <Mer_Col  <*30)  aad  (loft  Data(i)  .Taps* last)  loop 
sio.PotC  (Data(i).Taps(baft),  Top.povfl  * 

•er.Col)  } 

•er.col  io  Ser_Col  a  2  i 
baft  to  baft  ♦  1  9 
sad  loop  9 
aad  loop  t 

aad  Piaplay_Tapa_iyabo  la  i 

proeadora  Xaitialisa  (TapaJHo  t  Tapa.Paapat  Start  i  string)  ia 

baeiB  ^  Xaitialisa 
Xaitialisod  i-  tros  t 
Siaolatiap  t*  falaa  ; 

Data(T^*.Me).T^*  :•  (otbora  ■»*-*)  j 
Dsta(Taps  MO). Taps  (1. .Start* last)  i*  start  9 
Data(Tapa_Mo).Maad  !•  1  ) 

Data(Tap*.Me)  .Pigbt.lad  i*  Start' last  } 
if  On  Scrsaa  tbaa 
Dlaplay.0n  ; 
aad  if  9 

sad  Xaitialisa  9 

proeadora  Piaplay_0n  is 

Col  t  aatoral  9 

bagia  —  Diaplay_Oa 
On  Seraaa  t*  troo  9 
ii  XaitiaUsod  tbaa 

Xaitialisod  t*  falaa  9 
Siaolatiag  !■  tros  } 
for  i  ia  Tapa^Paaga  loop 
Cel  :•  Haad_Cel«n  * 


32 


<*1U  Cel  «•  M  loo* 

•ie.totc  (Oonec,  «ap_aa«  *  S«(l.l),  Cel)  | 

•le.XMC  (■efecetez,  Soft_BBit»l  >  Cel)  i 

•ie.fvtc  (Cenec,  ieK_Baw»]  *  S>(1-1),  cel)  i 
if  Cel  <  M  tkea 

•ie.MtC  («op,  *«.■«>'  *  S«(l.l),  Cel*!)  j 
■le.fotc  (tOD,  Tep.aew*!  *  5*(i-l),  Cel*l)  i 
•ad  If  1 

Cel  )-  Cel  *  2  I 

lAOp  I 

•io.Vttte  (K  W  iMd*  vop  rnam^i  ♦  S*(l-1),  iMd  OoIvM)  f 
•io.tvtc  <to«c«tov,  topJliait¥4  ♦  I 

•ad  iMip  I 

Oiaplay.Tava.Syabola  i 
•ad  if  I 

•ad  ]>ia]^Iay_Qa  i 
pcooadora  Dia|^y_Off  ia 

b«9ia  Diapiav  Off 

Oa  iosaoa  falaa  i 

•ad  Dia^y.Off  i 

prooadara  l»ad_Mad  (Tay»_ao  t  t^a.daao*  t 

■yabal  t  ia  oat  okaraatas)  ia 

ba^ia  ftaad  laad 

if  Xaitialia«3  os  •iaolaiiao  thoa 
ZaitiaXiaod  t*  faiaa  i 
•iaoiatiao  >*  traa  ) 

•yabol  !■  Data < T«ya_Ve )« Taps  (Data(Tapa_lo)«aaad)  i 

•laa 

saiaa  Yaao.Sssos  i 
•ad  if  I 

•ad  Aoad.laad  | 

prooadasa  llSit«_B«*d  (Tapajto  t  Tapa^saafa  t 

•yabel  t  ia  oat  okasaotar)  ia 

bapia  Wtita^baad 
if  Xaitiaiiaod''oE  Siaalatia^  tkaa 
Zaitiaiiaad  i«  falao  $ 

■ianlatiao  tsoa  | 

Oata(Tapa_Pe)  etapa  (Oata(Tapa_Po).Baad)  i*  tyatoX  } 
if  Qa  foraaa  tkaa 

olapiay  Tapa^tyoboia  $ 

•ad  if  I 

•Laa 

saiao  T^a  Issos  | 

•ad  if  I 

•ad  ttrit«_baad  t 

psooadara  Mova^Paad.Laft  (Tapa.Pe  i  Tapa^kaapa)  ia 

bapta  —  Nova  Paad.&oft 
if  XaitialiaaS  os  tiaoLatiap  tkaa 
Xaitialiaod  t«  faiaa  i 
•iaalatlap  t«  tsoa  i 
if  Oata(Tapajto)«la«d  •  1  tkM 
saiao  Tapa.Oadasflow  f 
•!•• 

Oata<Tapa  Po).Pa«d  s«  Data(Tapa  No)  .laad  -  1  i 
•ad  if  I 

if  Qa  anroan  tkaa 

Xf  Data(Tapa  No).Naad  <  Laft  idga  tkaa 

oio.NotN  <”  ”,  Top_Now  4  9«<TapaJNo.l), 

■••d_Colaaa-2«Oat4(Tapa  No).Naad-l)  } 
aioePatf  <*  ”,  Top_ao«r»l  ♦  9*(Tapa  No-l)* 

aa«d_Col«».2«Oat4(Tapa  Ho).Naad-l)  i 
•io.PotN  <*  *,  Top.NowfX  4  9«TTapa  No-l)* 

Naad.Col«ai-2*X»ata(Tapa_No).Naad-l)  ; 

•ad  if  f 

DiopIay.Tapo.tyakola  f 
•ad  if  f 

•!•• 

saiao  T^a.Bssos  f 
•ad  if  I 

•ad  nm.Naad.Xioft  i 

pcooodoso  Nooa^laad^Kipkt  (Tapa.Ho  i  Tapa.Naapa)  ia 

bapia  Moot  ■••d^Kipht 
if  Xaitialia^  os  Nlaalatlap  tk*a 
Xaitialiaod  $•  tmlmm  f 
Nlanlatiap  i*  tsaa  j 

if  Data(Vapa.No)eaaad  •  Data <tapa_No).Tapa' last  tkaa 
saiM  T^a.Oaasflow  | 

•lao 

Oata(V^  Ho). load  s«  l>ata(Tapa  Ho). load  4  1  i 
if  Oata(Tapa_Ho)eHaad  >  Data(Tapa_Ho).Hipkt.lad  tkaa 
Oata(Tapo_Ho)eHipkt.lad  i«  oata(T^_Hoy.Ha«d  i 
•ad  if  t 
•ad  if  I 

if  Oa_aosaaa  tkaa 

Xf  Oata(tapa_Ho).Haad  <*  Laft.tdpa  tkaa 

•io.PotH  (Cosaos  C  Hop,  «^_How  4  9*<Tapa_Ho-l)» 

l•ad_6olaa-2•Data(TlV•Jto).B•ad4l)  | 

•io.Pata  (Hopasatos  ft  llaak« 

Top  Hew4l  4  5*(Tapa  Ho-l), 
Haad_Col«Ba**2*Oata(Tapa_Ho).Haad41)  i 
•io.Pata  (Coraos  ft  Top*  Top.llow42  4  9*<tapajao-l), 
Hoad_ColiHai«2*Oata(TapajRo).Haad4l)  ; 

•ad  if  I 


Biaplay.Tapa.byabola  t 
•ad  if  I 
•lao 

saiaa  Taps  Issos  i 
•ad  if  I 

•^  Nava.Baad.lipkt  t 

psannhira  lad^Biaalatioa  ia 

bapia  --  lad^iiilattoa 
Xaitialiaod  t*  falao  t 
•iilatiap  io  faiaa  ) 

Oa  ftasaao  falao  i 
•M  lad.SiMBlatioa  i 

foaittiaa  Tapa.Iia*  (Tapa^Ho  t  Tapa_ftaapa)  sotosa  aatusal  ia 

bapia  —  Tapa_liao 

satasa  bata<Tapajto).lipkt_lad  t 

•ad  Tapa.ftiaa  i  ~ 

foaetioa  Tapa.Piooo  (Tapa_Ho  i  Tapa.laapa  i 
baft  f  aatosal  i*  1  ; 
kipkt  I  aatosal  )  satasa  atsiap  ia 

bap^i  Papa  Piaoa 

satasa  Oata(Tapa_Ho)  .Tapa  (Laft.  .ki|^t)  i 
•ad  Tapa.Piaoo  » 

foaotioa  Cassoat.ayakol  (Tapa_Bo  t  Tapa^laapa) 

r«tnsa  oharactos  ia 

bapia  <»*  Cassoat_ayBbol 
if  Xaitialiaod  os  liaalatiap  tkaa 

s«tasa  Data(9apa_Ho)  .Tapa  (Data(Tapa  Ho)  .load)  | 

•lao 

saiao  T^o  Issos  t 
•ad  if  ) 

•ad  Carsaat.lyabol  t 

foaotioa  Baad^Pooitioa  (Tapa_lo  i  Tapo_laapa)  sotusa  aatosal  ia 

bapia  Haad^Peaitioa 
satasa  Data (tipajto). load  t 
•ad  Baad.Paoitiaa  ) 

•ad  Tosiap_Tapa  | 
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8.3  Towers  of  Hanoi 


8.3.1  Programming  Assignment 

The  Towers  of  Hanoi  program  was  discussed  in  class.  A  copy  of  the  Hanoi  program  is  in 
/home^acalty/beidler/Qnpsl44/hanoi.ada 

You  can  see  how  the  program  executes  by  bringing  up  an  xterm  window  and  exeaiting 
/home^aculty/beidIer/Cmpsl44/hanoi 

Below  is  a  graph  of  the  number  of  disk  moves  required  to  complete  the  Towers  of  Hanoi  problem  with 
1  through  8  disks,  inclusive.  Note  that  the  number  of  moves  required  to  perform  the  Towers  of  Hanoi 
is 

d 

M(d)  »  2  -  1 

where  d  is  the  number  of  disks. 

127  255  511  1023  2047  4095 
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10+ 
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I  h/u  h/s 

- + - + - + - + - + - + - + - + — - — + - + - + - 

123456789  10 

The  Ole  /home/faculty/beidler/Cmpsl44/saigon.ada  omtains  a  partially  completed  Towers  of  Saigon 
program.  The  Towers  of  Saigon  is  like  the  Towers  of  Hanoi,  but  uses  four  spindles  instead  of  three. 
Gimplete  and  run  the  program  and  do  the  following: 

1.  Run  the  program  with  all  values  between  one  and  eight  disks. 

2.  Cut  and  paste  the  graph  above  and  plug  in  the  letter  ’s’  to  roughly  indicate  the  growth  pattern  for  the 
number  of  moves  required  to  solve  the  Towers  of  Saigon  with  between  one  and  eight  disks,  inclusive. 

3.  Include  with  your  submission  for  this  assignment  and  estimate  of  the  move  function  for  the  Towers 
of  Saigon  program. 

4.  Submit  the  information  above,  via  email,  with  a  .1st  of  your  program. 


8.3.2  Basic  Towers  of  Hanoi  Program 


witk  tty*  h«aol_tao«£d; 

proo«duir«  K«aoi  im 


nmtmxjOtJBfiakm  t  ocMutt^at  luitartti  <  ) 


peek«9»  is  mw 

li«aoi_Softrcl  (Se.Of.Sniiadlst  4/ 
Me_Of_olsks  «>  Ba 

OM  Bsw^bosrd  | 


psek«9s  tio  r« 


ia^stxliM 
first  ssas 


third 


I  string  (1  ..  40) f 
t  iatsgsr) 

I  positiss  !•  1  } 
s  positiaw  !•  2  ) 
t  positiss  3  } 


ir.Of^OisJcs  )  I 


Stsp^avriMT  I  lonoLintsgsr  i*  0  i 

psoesdars  toMsrs.of^hsaoi 
(  frca^spindls, 
hslp^spiadis, 

to.spiadls  s  in  positiss  i 

aanbsr^of^dislui  i  in  Intsgsr  )  is 


bsgin  of  towsrs_of_)isaoi 
if  atafMr.ef.disks  ■  1  thsa 

Stsp_mi£bsr  Stsp.Wibsr  4  i  p 
Moss  Sisk  (frsa^spindisf  to^spiadis)p 

—  tio.pnt  (*Stsp  *)} 

—  tio. pot 

— <loag_intogsr*iBap8  (Stop  Jnariwr))p 

—  tio.pot  ('t  Moss  s  disk  ?roB  *)i 
••  tio.pot 

—  (positiss'iasgs  (frosi^spiadls)  )| 
tio.pot  (*  to  *)| 

—  tio.pot  (pesitios'iwigs  (to.Bpindls)  )  | 

—  tio.aso.lins  p 

sis# 

—  Neos  sli  bat  ths  bottea  disk  to  tbs  *kslp*  spindls 
towsrs_of_ksiioi 

(  froa.spindis  «>  froo.spiadls, 

hslp.spindls  ■>  to  spindls  f 

to_spindlo  ^  bsTp_spindls« 

Aoibsr.of^disks  ■>  maabsrjof.disks  *1); 

— %%  Moss  tbs  bottsa  disk  to  ths  *to*  spiMUs 
towsrsjof.hsnoi 

(  frw.spindls  ■>  froa.spiadls* 

hsXp.spindls  •>  hslp.spindls, 

to_spiadls  ■>  to_spiadls» 

nsabsr^of^disks  *>1)7 

Moss  ths  disks  froa  ths  *bslp*  spindls  on  top  of  ths  big  disk 


towsrs.of.hsaei 

(  frsa_spindls  ■> 
hslp.spindls  ■» 
to  spindls 
ai^sr  of  disks 

sad  iit 

sad  towors.of.hsaoi} 

bsgin  of  hsaoi 

—  tio.pat(*8eo  asay  disks?  *)i 
tio.gst_lins(ia_string,  striag^siss)) 

—  a«bsr_of_disks  t*  iatsgsr*sslos(iB_string)r 
teasrs_.of.hssoi( 

frsa.spindls  ■>  first  asas, 

hslp_sptndls  ">  ssoond^asBS, 

to^spindls  third_asas» 

atorihsr  of  asobor  of  disks)! 

tty.Pot  ~(2r,  I,  loog_]atsgsr*iBsgs(Btsp  Bsabsr)  ) 
ltty.PBt(24,l,  •  •)  » 
sad  hsaoip 


hslp.spindls, 
frea.spindls, 
to.spisdls, 
atabsr.of .disks  -  l)i 
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8.3.3  Towers  of  Hanoi  Display  Package 


So_Of  Snijidi**  *  } 

Be.of .disks  t  yositiss  i 

ysokass  kssoi.bssxd  is 

Oisk.Bxsoc  I  sMosfkiss  i 


psoosAurs  asss.disk  (  frca.spisdls,  to.spisdls  :  is 
pesitiss  )  I 

ssd  ksssi.kossdi 


witk  sorsss.io  i 

—  witk  tty  I 

—  with  tMt.iO} 

psoksgs  body  kssoi.bosrd  is 

Ssss.Sow  I  eesstsst  sstsxsi  t«  20  i 

Disk.siss  I  oosstsnt  sstscsi  i«  (•e)/i«.of  Spisdiss  j 
ssbtyps  disk.strisg  is  string  (1  ..  oisk.siss)  t 

ssapis.dlsk  i  oosstsst  Sisk.Strisg  (othszs  «>  ; 

bXssksir  t  oosstsst  Disk.Strisg  (otksrs  i 

Bss.disks  i  oosstsst  istsgsr  t*  (0isk.Siss«2)  /  2  i 

sstotyps  stsok.rssgs  is  istsgss  rssgs  1  ..  sss.disksi 
typo  spisdio.srssy  is  scxsy  (stsok.sssgs)  of  sstscsl  i 
typo  spiadlslroooffd  is 
rooocd 

tep.disk  <  istogsx  t*  0  i 

Disk  I  spis^.scrsy  t«  (otksrs  ">  0)i 

sad  rsoostfj 

sabtyps  spisdls.cssga  is  istsgar  sssgs  1  ..  So  Of  Spisdlssi 
typo  bosxd.typs  is  ssrsy  (spisdlo.rssgs)  of  s^^Is.rooord; 

typo  spisd Is.ooloss.typs  is  ssrsy  (1  . .  Bo.Of.Spisdlos)  of 
istogar  | 

spisdlo.ooloBs  t  spisdlo.ooltaM.typo  $ 

hsBoi  t  taossd.typs  j 

fros.BOSbsr# 

to.aastoor  t  istogsc  $ 

Ccmt  t  astorsl  0  i 

pcoosdoKo  Oisplsy.Sisk 

(Soo,  CoIasB  t  astwsl  $  Disk  t  istogsc  >  is 

bogia  —  pisplsy.Oisk 
if  Disk  Ob  0  tbos 

—  tty.pot  <aow,  Coi«Bi4Disk«  BisBkor(l..(-Disk))  4  *{*  « 

Slsiikorll««(«Disk))  )  9 
sorooa  io.Pats  (SXsBkor(l..(«Diak))  4  *j*  4 

sIsafcor(t..(«Disk))«  Sow,  coliw^Disk  )  i 

oiso 

tty  .Pat  (BoWf  CoivS’-Oiskf  Ssepls.Oisk  (l..0isk)  4  *#*  4 
»  Ssssis  Disk  {l..Diskl  )  I 

soxooB.io.pots  (Sssplo  Disk  (1.  .Disk)  *4  *#*  4 
Sosplo.Disk  (l..Disk)«  Dow,  Coiws-Disk)  i 
sad  if  ) 

ssd  Diaplsy.Disk  i 

pcoeodaro  iaitisliao.bosrd  (lissoi  i  is  oat  bosrd.typo)  is 

Proeodaco  Dispisy.Spindlo 

(ColoBi  t  sstarsi  j  Spisdls  i  •pisdlo.Sseord)  is 

bsgis  —  Displsy.Spisdls 
£ar  1.  4b  Stsok  Bssss 

DispIsy.DlsE  (Ssso.Sow  -  i,  Oolvsi,  ^lsdlo.Oisk<i))| 

ssd  t 

•ad  Dlsplay.lpiadla  > 

baaiB  —  o<  ial«i*UM_ba«id 
.pladl*_aolMB  (1)  Diak_dla«/2  | 
for  1  ia  2  ..  ae.Of  Ipiadlas  loop 

■piadl.  Coliaa  (I)  t.  Spiadla^Colaat  (1-1)  *  Diak.dlMi 

—  t«at~io.>«e(iat«p.r’ia.p«(dpiadl*_Col«BB(i))» 

•ad  loop 

for  1  ia  1  ..  ■o_Of_Dlslu  loop 

■•aal(l).Diak(l)  >•  ao.Of.Oialu+l-i  t 

—  taat.le.tot  (iata(|ar'lB.«a(ao_of_Dialia.l-l))i 
•ad  loop 

■•aei(l).*op_Dlak  do.Of.Olalta  | 

— tty.claar  deraao  i 
•eraaB_io.Cla.r  ) 

— tty.Pot  (■aaa.Bow,  1, 

•eraoa  io.fota  ( 

,  Ssso.SoWp  1)  ; 


for  i  is  1  ..  Bo  Of.spisdiss  Loop 

DispLsy.^i sd Is  (Sp<ndls.CoLam(i),  Bsaoi(i)  )  i 
ssd  Loop  I 

ssd  isitisLiss_bosrd| 
prooodsco  BOos_disk 

(  fsoB.spisdlSy  to.spisdlo  t  is  positiwo  )  is 
ktaoos,  BsLow  I  istsgsr  i 


DispLsy.Disk  (Ssso.Sbw  Bssoi  (Yo.l^isdLo)  .Top.Disk  -  1, 
**  SpisdLs.CoLsBS  (To.BpisdLo)* 

Bssoi (Proo.spisdio). Disk ( Bssoi (Prao.^^isdLo).Top.Disk)  ); 

DispLsy.Disk  (Boss  Bow  Bssoi  (Proo_SpisdLs)  .Top_Disk, 

'  Sptsi  Ls.CoLass  ( rroo~spiadls ) , 


•^BssoitVtcn.Spisdis)  .Disk(Bssoi(Prao.SpisdLo )  .Top.Disk )  )  t 

Bssoi (Po.SpiadLo).eop.Disk  i*  Bssoi (To.SpisdLs) .Tep_Oisk4 it 
Bssoi  ( foT  SpisdLs  )  .DU&(  Bssoi  (Do  SpisdLo)  .Dop.Dlsk)  i* 
Bssoif^rsB  SpiBdIs).Disk(BssM(Pxoa  spisdLs).fap  Disk); 
Bssoi  (Pxosi.SplsdLs) .  Disk  ( Bssoi  ( Pxtoa.SplsdLo )  .Top.Di^) 

I*  •  9 

Bssoi ( Pxoo.SpisdLs )  .Dop.Diak  !• 

Bssoi (Pxoo.SpisdLs )  .Dop.Disk»l  t 

Coast  t*  Cott  *  1  t 

»tty.Pat  (2*  SOf  ‘Booss  •  *  4  istsgsx * iasgs ( Coast ) )  t 
soroos.io.Pats  (‘Nosos  •  *  4  istsgsr *iasgs( Coast)  ,  3,  SO)} 
••tty.Pat  (22,  I,  *  *)  > 
sexsos.io.fats  (*  *,  22,  I)  } 

—  <lsLsy  0.001  9 

for  i  is  1  ..  32747  Loop 

saLL  f 

ssd  Looo  t 

— tty.pat  (3,3, ‘if  •)  } 

if  (Bssoi(Do  OpisdLs).top  Disk  >  1)  tbss 
->tty.tat  (3,3,‘isssx  if*^)  i 
— tty. Pat  (4,3,  istogsx'lss^  (Do.OpisdLs))} 

->-tty.PBt 

(S,3,  istogsr'isogs  (Bssoi ( To^Spisdls)  .Top.Disk)  )t 
—tty.pot  (4,3,  istsgsr  *iBsgs 

(Bssoi(To.SpisdLo)  •Disk(Bssoi(«o.SpisdLs)  .top.Oisk) ) ) ; 
—tty.pot  (7,3,  ists»gsx*tsiiags 
(Bssoi  (fo.tptsdlo) .  Disk  ( Bssoi  (fo.OpisdLs )  .Top.Disk<»l ) ) ) ; 


BMoi  ( to.episdLo ) .  Disk  ( Bssoi  ( VD.Opisdis ) .  fop.Disk ) ; 

DsLow  SB 

Bssoi(fo.OpiBdlo) .  Disk  ( Bssoi  ( Do.SpisdLo )  .Top.Disk- 1 ) ; 
if  Bbeoa  >  BsLow  tbos 
xsiso  Disk.Bxxox  9 
sad  if  ) 

—tty.pot  (3,3,‘sKit  isssx*)  } 
sad  if  I 

—tty.pot  (3,3,  *ooit  ootox*)  } 
sad  ■ewo.diskr 


bsgis  kssoi.bosxd 
if  Bo.Of.Disks~>  Nss.Disks  tbos 
xsiso  ooastxsist'sxxox  i 

oLso 

isitisLiss.bosxd  (bssoi)  } 
sad  if  } 

sad  bsaoi.bosxd} 
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8.3.4  Towers  of  Saigon  Sample  Code 


—  Coefxialit  (o)  19fl«1992  JoImi  SsidiMT 

VmXw.  of  Scs«atco,  Sesooteof  as  ttSid 

(711)  94l-744<  ooioo 
(117)  941-4290  rai 
taoidloc  tfOiOMM  .  o« .  «of  • .  oOb 

—  boidlocOocsBotoo  (SitMtl 

—  FOB  BOO  hf  Bdo-profit  odnootioMl  iootitotioM  ooly. 

—  Tkio  ooftooro  io  eOMUynm.  auooo  Bosect  ooy  OBBOBB.  all 

—  ooBsoetioiio  will  So  aodo  ••  oooo  oo  poootblo  (OMSolly 

—  witSio  mm  oobSIos  doy). 

wits  toot.io,  koooi.booBdi 
pcooodoBO  Soieeo  io 


tpworo_of_soiepo( 
fBO»_^odlo 
SolfLopiiidlo 
Bolft.2.S»io41o 
to.ofiodlo 
SmSm  of_dloko 
ood  iot.aioeloy  i 


1, 

2« 

2, 

4, 


hofio  —  of  SoifDO 

tio.oatf*Bow  Booy  diokoT  *)t 

iio.fot  (ao^Of^wLko)  I  tio.0kia.Liao  i 

Oot_Dioaioy  (Bo  Of  Oioko)  I 

—  tty.tot  (22,  l,~ioof_iof  forM— 9o(0top  Si 

—  tty.avt(24,l,  *  *)  I 

fo«t_lo.eot_Lioo  (Xo_otBioe,  Otrima_Siao)  j 

ood  Ooifoo} 


ootatyao  Diok.Booeo  io  iotoeoB  xmgB  1  ..  9  t 
aopkoeo  tio  roooaoo  foot  20  $ 

pookoeo  iio  io  now  «oat.lo.iatoeoB.io(iatoeoB)  } 

in.otBiao  t  otBine  (1  ..  40)i 

otBine_oiao  t  intofOBi 

So.Of.Oioko  I  Diok.aoneo  t 

9top>_naBboB  i  loAf_iatoeoB  i*  4)  | 

aBOOodOBO  Sot^Dioploy  (StnboB.Of^Bioko  t  in  iotoeoB)  io 

poekogo  Sow.booBd  io  now 

honoi_booBd  ( So_of .Osindioo  •>  4, 

So.of 'oioko  •>  s«abOB_Of_Oioko  )  $ 

BOO  SOW_taOOBd  I  '  '  ~  ' 


pcooodBBO  towaBO_,of.9oieon 
(  fBoa  opindlo,  ' 
holp.opindlo, 
ao  la_2_opindlo , 

to^opindlo  I  in  pooitioB  i 

soeboB.Of^dioko  i  in  iotogoB  )  io 


»  tio. put  (intogoB'inoeo  (So  Of.Oioko)  )i  tio.Sow.Liao} 
Oooo  BBiiboB.Of^Dioko  io 
^dMn  1  ■> 

Nooo.Oiok  (froe.Spindlo,  fe.tpindlo)  f 
Stop.aBshoB  !•  Stop.awikoB  *  1  I 


towoBO.Of.toigao 


TOwaBo_Of_9oigoB 


TowoBo_Of_,Ooigon 


«Aon  otkoBO  •> 

TowoBO_Of_9aieoB 


TowoBO^Of^Soigon 


eowoBO.Of_Soi5|oo 


TowoBO_Of_Soigen 


towoBO_Of_Soigoti 


ond  oooo  f 


(fxm  tpindlo, 
snip  2  Spia^, 

TO  Spiadio, 

Snip  ipindlo, 

I  )  I 

( FBoa.SpiBdlo , 

Bo lp'2_9pindlo « 

Bo  lp_9piadlo , 

To  Spiadlo, 

I  T  I 

(Bolp^Spindlo, 

Bo  lp_2.Bpiadlo , 
FBoa.Bpindlo , 
To.Spindlo, 

I  )  I 

( r  Boe.Spiadlo , 

Bolp.2_BpiBdlo « 

To  Spindlo# 
Bolp_Bpindlo, 
BBSbOB.Of  Dioko-2)  I 

( y  BCB_9pia3lo , 
Bolplspindlo, 
Po.Spindlo, 
Bolp_2_9pijidlo , 

1  )  I 

( PBoa.Bpiadlo, 

Bo  lp'2.Spindlo , 
Bolp.ipindlo, 

TO  Spindlo, 

1  >  I 

( Bo  lp.2_Spindlo , 
rBca.tpiadlo, 
Bolp.Bpindlo, 

To  Bpiadlo, 

I  )  t 

(Bolp.SpiBdlo, 
Bolp_2.SpiBdlo, 
FroB^Spindlo, 
To^tpindlo, 
BvibOB.Of_l>ioko-2 )  I 


ond  towoBO_of_9oigefi| 
bogin  —  Bot.Dioploy 
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